fix(skill-sync): relax adopt name check

.agents/skills/add-provider/SKILL.md

@@ -78,8 +78,8 @@ Typical files:
 
 ## Workflow
 
-1. Read `docs/features/provider-runtime/spec.md`, `plan.md`, and `tasks.md` when the provider work
-   touches the provider runtime scope.
+1. Read `docs/features/provider-runtime/spec.md` when the provider work touches the provider runtime
+   scope. Also read `plan.md` and `tasks.md` if they exist for an active provider-runtime goal.
 2. Inspect the current provider files before editing:
    - `src/main/presenter/configPresenter/providers.ts`
    - `src/main/presenter/configPresenter/providerId.ts`
@@ -90,7 +90,7 @@ Typical files:
 3. Classify the request into one supported path.
 4. Add the smallest explicit source changes for that path.
 5. Add or update tests that prove provider creation, auth handling, and model discovery behavior.
-6. Update the active SDD `tasks.md` entries as the work lands.
+6. Update the active SDD `tasks.md` entries as the work lands, when an active tasks file exists.
 7. Run:
 
 ```bash

.agents/skills/deepchat-sdd-cleanup/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: deepchat-sdd-cleanup
+description: Use only when a developer explicitly asks to clean, prune, tidy, or organize DeepChat SDD documentation after implementation and validation. Scans docs/features, docs/issues, and docs/architecture; prefers multi-agent review when available; removes completed issue docs tied to closed GitHub issues, drops stale plan/tasks files from completed feature or architecture goals, and deletes obsolete feature or architecture docs.
+---
+
+# DeepChat SDD Cleanup
+
+## Rule
+
+Run this skill only when the developer explicitly asks for SDD cleanup, documentation tidying, pruning,
+or removal of completed/stale SDD files. Do not run it as an automatic final step of ordinary
+feature, bug, architecture, or release work.
+
+## Workflow
+
+1. Inspect `docs/spec-driven-dev.md`, `docs/README.md`, and `git status`.
+2. Inventory `docs/features`, `docs/issues`, and `docs/architecture` with `find` or `rg`.
+3. Prefer parallel sub-agent review when available:
+   - one pass for `docs/features`
+   - one pass for `docs/issues`
+   - one pass for `docs/architecture`
+   - optional verifier pass over proposed deletes
+4. Apply only changes with clear evidence. Keep a concise keep/delete/update list for handoff.
+5. Validate references after edits.
+
+## Cleanup Rules
+
+- Completed feature or architecture goal: delete `plan.md` and `tasks.md`; keep `spec.md` only when
+  it still defines a maintained contract, regression guard, platform policy, or architecture
+  decision.
+- Completed issue goal: delete the issue folder when a linked GitHub issue is closed or the local
+  code and tests prove the bug no longer exists.
+- Removed feature: delete its folder when the product/code path is gone and the spec has no reusable
+  decision record.
+- Obsolete architecture: delete its folder when the module was fully replaced and the doc no longer
+  describes a maintained boundary; otherwise update the spec.
+- Historical feature spec affected by an architecture refactor: update the retained spec instead of
+  leaving contradictory docs.
+
+## GitHub Checks
+
+Use `gh` only when it is installed and authenticated. For linked issue docs, verify closure with
+`gh issue view <number> --json state,url,title` when possible. If `gh` is unavailable, do not delete
+solely because a GitHub link looks old.
+
+## Never Delete
+
+- Active work with unchecked tasks.
+- Any document containing unresolved `[NEEDS CLARIFICATION]`.
+- A document referenced by `docs/README.md`, `docs/ARCHITECTURE.md`, `docs/FLOWS.md`, or AGENTS
+  instructions unless the reference is updated in the same change.
+- Runtime baselines or machine-read files unless the cleanup request explicitly covers them.
+
+## Validation
+
+- Run `rg -n "plan.md|tasks.md|docs/archives|NEEDS CLARIFICATION" docs AGENTS.md .agents/skills`
+  and inspect any stale policy references.
+- Run `git status --short`.
+- For Markdown-only cleanup, formatting/lint commands are optional unless repository instructions or
+  touched generated files require them.

.agents/skills/deepchat-sdd-cleanup/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "DeepChat SDD Cleanup"
+  short_description: "Prune stale DeepChat SDD documentation"
+  default_prompt: "Use $deepchat-sdd-cleanup only when the developer explicitly asks to clean, prune, tidy, or organize DeepChat SDD docs."

.agents/skills/deepchat-sdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: deepchat-sdd
-description: Use for any DeepChat code, configuration, documentation, feature, issue fix, refactor, or architecture change before implementation. This skill enforces the project SDD workflow: classify the goal, create or update spec.md, plan.md, and tasks.md under docs/features, docs/issues, or docs/architecture, resolve NEEDS CLARIFICATION items, then implement and validate.
+description: Use before DeepChat code, configuration, documentation, test, build, feature, issue, refactor, or architecture changes. Classify work into feature SDD, small-bug issue spec, or architecture SDD; optionally sync feature and bug work to GitHub issues with [feature] or [bug] labels when local gh is usable; keep broad documentation cleanup for the separate deepchat-sdd-cleanup skill.
 ---
 
 # DeepChat SDD
@@ -14,40 +14,68 @@ Use this skill before changing DeepChat source code, configuration, tests, docs,
 Create one kebab-case folder per goal:
 
 - New capability, user-visible behavior, integration, or tool: `docs/features/<goal>/`
-- Bug, regression, failing test, CI failure, reliability problem, or prompt/runtime issue: `docs/issues/<goal>/`
-- Refactor, migration, dependency boundary, shared contract, runtime architecture, or cross-module design: `docs/architecture/<goal>/`
+- Small bug, regression, failing test, CI failure, reliability problem, or prompt/runtime issue:
+  `docs/issues/<goal>/`
+- Refactor, migration, dependency boundary, shared contract, runtime architecture, or cross-module
+  design: `docs/architecture/<goal>/`
 
 If one request contains multiple independent goals, split them into separate folders. Keep current architecture reference docs such as `docs/architecture/agent-system.md` in place; use subfolders for new architecture targets.
 
+Treat a bug as small only when the failure is narrow, the owner module is clear, and the fix does not
+introduce a new user-visible capability, data migration, public contract, or cross-module redesign.
+If it does, classify the work as feature or architecture instead.
+
 ## Required Artifacts
 
-Every active goal folder must contain:
+Feature and architecture goals use the full SDD set:
 
 - `spec.md`: user need, goal, acceptance criteria, constraints, non-goals, open questions
 - `plan.md`: implementation approach, affected interfaces, data flow, compatibility, test strategy
 - `tasks.md`: ordered tasks that can map to commits or review slices
 
-Resolve every `[NEEDS CLARIFICATION]` marker before implementation. If a requested change is tiny, keep the files short and concrete.
+Small bug goals use one file only:
+
+- `spec.md`: issue description, impact, root cause or suspected location, fix plan, task checklist,
+  validation, and linked GitHub issue if one exists
+
+Resolve every `[NEEDS CLARIFICATION]` marker before implementation. If a requested change is tiny,
+keep the artifact short and concrete.
+
+## GitHub Issue Sync
+
+For feature and small bug goals only, sync to GitHub when local `gh` is installed and authenticated:
+
+- Feature issues use the `[feature]` label.
+- Bug issues use the `[bug]` label.
+- Create the label first if it is missing and `gh` has permission.
+- Record the issue URL or number in the SDD artifact.
+- If `gh` is unavailable or unauthorized, continue local-only and note that no GitHub issue was
+  created.
+
+When creating a PR for linked work, include `Closes #NNN` in the PR body so GitHub closes the issue
+automatically after merge.
 
 ## Workflow
 
 1. Inspect the current code and docs first.
 2. Pick the target folder from the classification rules.
-3. Create or update `spec.md`, `plan.md`, and `tasks.md`.
-4. Keep the implementation aligned with existing DeepChat patterns:
+3. Create or update the required artifact set for that classification.
+4. Sync a GitHub issue for feature or small bug work when `gh` is usable.
+5. Keep the implementation aligned with existing DeepChat patterns:
    - main process Presenter boundaries
    - typed `shared/contracts/*`
    - renderer `api/*Client`
    - Vue 3 Composition API and i18n for UI strings
-5. Implement the change after the SDD artifacts are complete.
-6. Update `tasks.md` as work lands.
-7. Run `pnpm run format`, `pnpm run i18n`, and `pnpm run lint` before handoff.
-8. After implementation is accepted and validation passes, delete `plan.md` and `tasks.md` for
-   that goal; keep `spec.md` as the durable contract.
+6. For architecture work that changes or replaces a historical feature, update that feature's
+   retained `spec.md` if it is still a maintained contract.
+7. Implement the change after the SDD artifacts are complete.
+8. Update `tasks.md` or the issue spec checklist as work lands.
+9. Run `pnpm run format`, `pnpm run i18n`, and `pnpm run lint` before handoff.
 
 ## Documentation Hygiene
 
-- Move completed or stale SDD target folders to `docs/archives/<goal>/`.
-- Add an archive note when a document references historical code paths.
-- Delete documents that only describe removed code and have no reusable decision record.
-- Update `docs/README.md` when a moved document remains part of the navigation surface.
+- Do not perform broad SDD cleanup during ordinary feature, bug, or architecture work.
+- Use the separate `deepchat-sdd-cleanup` skill only when the developer explicitly asks to clean or
+  organize SDD documentation.
+- During the current goal, update directly affected historical specs when they remain active
+  contracts.

.agents/skills/deepchat-sdd/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "DeepChat SDD"
-  short_description: "Prepare SDD specs before DeepChat changes"
-  default_prompt: "Use $deepchat-sdd before implementing DeepChat changes to classify the goal and prepare spec, plan, and tasks artifacts."
+  short_description: "Classify DeepChat changes before implementation"
+  default_prompt: "Use $deepchat-sdd before implementing DeepChat changes to choose the right feature, issue, or architecture artifact workflow."

AGENTS.md

@@ -54,12 +54,14 @@ Follow the SDD methodology before changing code, tests, configuration, documenta
 Pure release metadata work does not require SDD. Version bumps, `CHANGELOG.md` updates, release branch management, tags, and release PR preparation should follow [docs/release-flow.md](docs/release-flow.md) without creating
 `docs/features/*release*` folders.
 
-Create one kebab-case folder per goal and keep `spec.md`, `plan.md`, and `tasks.md` together:
+Create one kebab-case folder per goal and use the artifact set that matches the work:
 
-- `docs/features/<goal>/` for new features, user-visible capabilities, integrations, and tools.
-- `docs/issues/<goal>/` for bug fixes, regressions, failing tests, CI failures, reliability issues, and prompt/runtime problems.
-- `docs/architecture/<goal>/` for refactors, migrations, dependency boundaries, shared contracts, runtime architecture, and cross-module design.
+- `docs/features/<goal>/` for new features, user-visible capabilities, integrations, and tools; keep `spec.md`, `plan.md`, and `tasks.md`.
+- `docs/issues/<goal>/` for small bug fixes, regressions, failing tests, CI failures, reliability issues, and prompt/runtime problems; keep one `spec.md` containing issue details, location/root cause, fix plan, task checklist, validation, and linked GitHub issue when available.
+- `docs/architecture/<goal>/` for refactors, migrations, dependency boundaries, shared contracts, runtime architecture, and cross-module design; keep `spec.md`, `plan.md`, and `tasks.md`, and update affected historical feature specs when they remain maintained contracts.
 
-Resolve every `[NEEDS CLARIFICATION]` item before implementation. Move completed or stale goal folders to `docs/archives/<goal>/`; delete documents that only describe removed code and have no reusable decision record.
+For feature and small bug work, create or link a GitHub issue with `[feature]` or `[bug]` when local `gh` is installed and authenticated. PR bodies for linked work must include `Closes #NNN`.
+
+Resolve every `[NEEDS CLARIFICATION]` item before implementation. Run SDD cleanup only when the developer explicitly asks for it; use the dedicated cleanup skill to remove completed issue docs, stale plan/task files, and obsolete feature or architecture docs.
 
 Core principles: specification-first, architectural consistency, minimal complexity, compatibility/migration awareness.

docs/README.md

@@ -1,8 +1,8 @@
 # DeepChat 文档索引
 
-本文档反映 `2026-06-25` 的当前代码结构。历史 SDD 已清理为“活跃目标保留三件套、
-已落地目标只保留 durable spec”的模型：`plan.md` / `tasks.md` 只服务当前执行，已完成目标
-只在 `spec.md` 保留仍有维护价值的契约和回归语义。
+本文档反映 `2026-07-05` 的当前代码结构。SDD 已按目标类型拆分：feature 和
+architecture 使用三件套，small bug 使用单个 issue `spec.md`。文档清理只在开发者明确触发
+`deepchat-sdd-cleanup` 时执行。
 
 当前 renderer-main 默认路径是 typed client / typed event：
 
@@ -33,7 +33,7 @@ shared contracts 进入；少数仍需要 raw IPC 的能力只能封装在明确
 | [guides/code-navigation.md](./guides/code-navigation.md) | 当前代码导航入口 |
 | [guides/getting-started.md](./guides/getting-started.md) | 新开发者快速上手 |
 | [guides/plugin-packaging.md](./guides/plugin-packaging.md) | `.dcplugin` 打包、内置分发和 release 规则 |
-| [spec-driven-dev.md](./spec-driven-dev.md) | SDD 目录规则、保留期限与清理规则 |
+| [spec-driven-dev.md](./spec-driven-dev.md) | SDD 目录规则、GitHub 同步与清理入口 |
 
 ## 仍有运行时用途的基线
 
@@ -60,7 +60,7 @@ docs/
 ├── features/
 │   └── <active-feature-goal-or-retained-contract-spec>/
 ├── issues/
-│   └── <active-issue-goal-or-retained-regression-spec>/
+│   └── <small-bug-issue-spec>/
 ├── guides/
 │   ├── getting-started.md
 │   ├── code-navigation.md
@@ -70,13 +70,15 @@ docs/
 
 ## SDD 保留规则
 
-- `docs/features/**`、`docs/issues/**`、`docs/architecture/**` 下的 active goal folder 保留
-  `spec.md`、`plan.md`、`tasks.md`。
-- 已实现能力只保留仍有维护价值的 `spec.md`；删除对应 `plan.md` / `tasks.md`。
+- `docs/features/**` 和 `docs/architecture/**` 下的 active goal folder 保留 `spec.md`、
+  `plan.md`、`tasks.md`。
+- `docs/issues/**` 下的小 bug goal 只保留一个 `spec.md`，内容包含 issue 描述、定位、
+  修复计划、任务清单、验证方式和 GitHub issue 链接（如有）。
+- feature / architecture 的已实现能力只保留仍有维护价值的 `spec.md`；删除对应
+  `plan.md` / `tasks.md`。
 - 已实现能力的当前维护事实也要并入 `README.md`、`ARCHITECTURE.md`、`FLOWS.md` 或对应 guide。
-- bug 修复类 issue SDD 超过两周即清理；按当前日期 `2026-06-25`，本次清理 cutoff 为
-  `2026-06-11` 之前。
-- 过期、未开工、只描述旧实现或旧分支的 SDD 直接删除。
+- 已修复 issue，尤其是关联 GitHub issue 且已关闭的，可以在手动 SDD cleanup 时删除。
+- 过期、未开工、只描述旧实现或旧分支的 SDD，在手动 SDD cleanup 时删除。
 
 ## 阅读建议