@gong-ym/ai-spec-auto 0.2.15 → 0.2.17

package/.agents/commands/common/spec-continue.md

@@ -61,7 +61,7 @@
 若 `turn.status = blocked` 且存在 `turn.summary.pending_gate`：
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/design/tasks 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/tasks 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-start-review.md

@@ -61,7 +61,7 @@
 
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 `proposal/specs/design/tasks` 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 `proposal/specs/tasks` 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update（协议更新命令）` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-start.md

@@ -48,7 +48,7 @@
 若 `turn.status = blocked` 且存在 `turn.summary.pending_gate`：
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/design/tasks 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/tasks 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-update.md

@@ -40,7 +40,7 @@
    - `resume-paused-run`：说明已恢复停点，再按返回的下一个 `turn` 继续
 2. 若返回 `turn.mode = update-review`，必须先遵守 `turn.guidance.update_contract`
 3. 只读取 `turn.reads`，只写 `turn.writes`
-4. 若 `change_impact = patch | scope-delta | archive-fix`，默认在同一 `change_id` 内增量更新，不要推倒已有 proposal/specs/design/tasks/checklist/iterations
+4. 若 `change_impact = patch | scope-delta | archive-fix`，默认在同一 `change_id` 内增量更新，不要推倒已有 proposal/specs/tasks/checklist/iterations
 5. 若 `change_impact = re-scope`，不要强行吞进当前 run；按 `reconcile_strategy` 给出“建议新建 change”的最小结论
 6. 若 `change_impact = followup-patch`，这是对已归档变更的补丁修正；继续沿返回的 patch run 推进，不要改旧 archive 目录
 7. 若存在 `turn.finalize_contract`，完成当前轮次后按契约推进，不要自行拼命令
@@ -57,4 +57,4 @@
 - 大段协议日志
 - scratch JSON
 - 内部运行态文件名
-- “整份重写 proposal/tasks/design/specs” 这类误导性说法
+- “整份重写 proposal/tasks/specs” 这类误导性说法

package/.agents/commands/cursor/opsx-apply.md

@@ -28,7 +28,6 @@ description: Cursor 兼容入口：按 tasks.md 执行 OpenSpec 任务实现
    ```
    再读取：
    - `openspec/changes/<change-name>/proposal.md`
-   - `openspec/changes/<change-name>/design.md`（若存在）
    - `openspec/changes/<change-name>/tasks.md`
 
 3. 默认按 `execute-task` 技能执行  

package/.agents/commands/cursor/opsx-propose.md

@@ -43,7 +43,6 @@ description: Cursor 兼容入口：创建 OpenSpec 提案并生成 proposal/spec
 5. 产物位置必须稳定落在：
    - `openspec/changes/<change-name>/proposal.md`
    - `openspec/changes/<change-name>/specs/`
-   - `openspec/changes/<change-name>/design.md`
    - `openspec/changes/<change-name>/tasks.md`
 
 6. 完成后只做简洁收口：

package/.agents/flows/RUN_OUTPUT.md

@@ -57,7 +57,6 @@
     "artifacts": [
       "openspec/changes/<change-id>/proposal.md",
       "openspec/changes/<change-id>/specs/",
-      "openspec/changes/<change-id>/design.md",
       "openspec/changes/<change-id>/tasks.md",
       "code",
       "openspec/changes/<change-id>/checklist.md",
@@ -129,7 +128,6 @@
   "artifacts": [
     "openspec/changes/add-user-center/proposal.md",
     "openspec/changes/add-user-center/specs/",
-    "openspec/changes/add-user-center/design.md",
     "openspec/changes/add-user-center/tasks.md",
     "openspec/changes/add-user-center/checklist.md",
     "openspec/changes/add-user-center/iterations.md"

package/.agents/flows/common/prd-to-delivery.md

@@ -25,7 +25,6 @@ approval_gates: []
 artifacts:
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
   - code
   - openspec/changes/<change-id>/checklist.md
@@ -119,7 +118,6 @@ domains:
 
 - `openspec/changes/<change-id>/proposal.md`
 - `openspec/changes/<change-id>/specs/`
-- `openspec/changes/<change-id>/design.md`
 - `openspec/changes/<change-id>/tasks.md`
 - 与本次变更相关的代码实现
 - `openspec/changes/<change-id>/checklist.md`
@@ -131,7 +129,6 @@ domains:
 
 - 需求边界已被收敛为 `proposal.md`
 - 增量规范已落在 `specs/`，且允许按 domain 拆分多份 spec
-- 技术方案已沉淀为 `design.md`
 - 实施任务已被拆解为 `tasks.md`
 - 代码实现与任务范围一致
 - 交付前检查已完成并形成 `checklist.md`

package/.agents/flows/common/requirement-to-observability.md

@@ -20,7 +20,6 @@ optional_roles:
 approval_gates: []
 artifacts:
   - openspec/changes/<change-id>/proposal.md
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
   - event-plan
   - tracking-schema-notes
@@ -78,7 +77,6 @@ domains:
 至少要沉淀以下内容：
 
 - `proposal.md`
-- `design.md`
 - `tasks.md`
 - `event-plan`
 - `tracking-schema-notes`

package/.agents/orchestration/task-orchestrator-run-plan-template.md

@@ -236,8 +236,8 @@ description: 定义 task-orchestrator 在首次识别任务时必须输出的最
 对于 `prd-to-delivery（需求到交付）`：
 
 - 首轮 `run-plan（运行计划）` 必须确定稳定 `change_id（变更 ID）`
-- 首轮 `run-plan（运行计划）` 必须显式带出 `proposal/specs/design/tasks/checklist/iterations` 的目标路径
-- 未存在 `proposal.md`、`specs/`、`design.md` 与 `tasks.md` 时，不得交给 `frontend-implementer（前端实现专家）`
+- 首轮 `run-plan（运行计划）` 必须显式带出 `proposal/specs/tasks/checklist/iterations` 的目标路径
+- 未存在 `proposal.md`、`specs/` 与 `tasks.md` 时，不得交给 `frontend-implementer（前端实现专家）`
 - 未存在 `checklist.md` 与 `iterations.md` 时，不得进入 `complete（完成）`
 
 ## 6. 示例

package/.agents/registry/flows.json

@@ -21,10 +21,10 @@
         "frontend-implementer->code-guardian": "silent",
         "code-guardian->archive-change": "silent"
       },
-      "core_artifacts": ["proposal", "specs", "design", "tasks", "checklist", "iterations"],
-      "required_artifacts": ["proposal.md", "specs", "design.md", "tasks.md", "checklist.md", "iterations.md"],
+      "core_artifacts": ["proposal", "specs", "tasks", "checklist", "iterations"],
+      "required_artifacts": ["proposal.md", "specs", "tasks.md", "checklist.md", "iterations.md"],
       "handoff_policy": "task-orchestrator -> requirement-analyst -> frontend-implementer -> code-guardian -> archive-change(可选) -> terminal",
-      "completion_policy": "proposal.md、specs/、design.md、tasks.md、checklist.md、iterations.md 缺一不可；默认自动进入 archive-change，如需人工审核可切换到 main-flow-blocking"
+      "completion_policy": "proposal.md、specs/、tasks.md、checklist.md、iterations.md 缺一不可；默认自动进入 archive-change，如需人工审核可切换到 main-flow-blocking"
     },
     "bugfix-to-verification": {
       "name": "缺陷修复到验证",
@@ -101,8 +101,8 @@
       "optional_roles": ["error-tracker", "rum-analyst", "code-guardian"],
       "first_handoff": "requirement-analyst",
       "approval_gates": [],
-      "core_artifacts": ["proposal", "design", "tasks", "event-plan", "tracking-schema-notes"],
-      "required_artifacts": ["proposal.md", "design.md", "tasks.md", "event-plan"],
+      "core_artifacts": ["proposal", "tasks", "event-plan", "tracking-schema-notes"],
+      "required_artifacts": ["proposal.md", "tasks.md", "event-plan"],
       "handoff_policy": "task-orchestrator -> requirement-analyst -> event-instrumentation-specialist -> error-tracker/rum-analyst(可选) -> code-guardian(可选) -> terminal",
       "completion_policy": "观测目标、事件口径与追踪建议已收口；若启用附加专家，则需补齐错误或 RUM 观察结论"
     },

package/.agents/registry/roles.json

@@ -149,7 +149,7 @@
       "rule_contract_profiles": {
         "default": {
           "must_follow": [
-            "先把项目定位、目录落点、规范约定吸收到 proposal/specs/design/tasks，不要把规范已明确的信息重复写成 missing_inputs。",
+            "先把项目定位、目录落点、规范约定吸收到 proposal/specs/tasks，不要把规范已明确的信息重复写成 missing_inputs。",
             "需求收敛必须落到当前仓库可实施的具体落点，而不是抽象方案。"
           ],
           "blocked_when": [
@@ -184,13 +184,11 @@
       "openspec_rule_sections": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -248,11 +246,11 @@
         "default": {
           "must_follow": [
             "优先复用现有目录、路由、请求封装、状态管理和样式变量约定。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "vue": {
@@ -270,13 +268,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -312,11 +308,11 @@
         "default": {
           "must_follow": [
             "优先复用现有 Service、Repository 和工具类，不重复建设。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "springboot": {
@@ -333,13 +329,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -375,11 +369,11 @@
         "default": {
           "must_follow": [
             "优先复用现有工具函数、Contract 定义和模块导出，不重复建设。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "node-tooling": {
@@ -396,13 +390,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -500,7 +492,7 @@
       "rule_contract_profiles": {
         "default": {
           "must_follow": [
-            "以 proposal/specs/design/tasks 和项目规则为准检查实现，而不是只做泛化 lint。",
+            "以 proposal/specs/tasks 和项目规则为准检查实现，而不是只做泛化 lint。",
             "必须给出阻断项、非阻断项和交付建议，不能写成模糊建议列表。",
             "若实现阶段经历过 auto-fix 仍未通过 verification，必须按阻断项处理，不能以后续再看放行。"
           ],
@@ -513,7 +505,7 @@
             "核查页面是否落在 src/views、路由是否落在 src/router/modules，并保持动态导入。",
             "核查 API 是否通过 src/api 封装、类型是否放在 src/api/types，页面中未直接调 request。",
             "核查样式是否使用主题变量、scoped 或 CSS Modules，而不是硬编码全局样式。",
-            "核查 Pinia/store、mock 与 proposal/specs/design/tasks 的边界是否一致，避免演示页写成生产页。"
+            "核查 Pinia/store、mock 与 proposal/specs/tasks 的边界是否一致，避免演示页写成生产页。"
           ]
         },
         "springboot": {
@@ -539,14 +531,12 @@
       "openspec_rule_sections": [
         "tasks",
         "specs",
-        "design",
         "checklist",
         "iterations"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": [
@@ -586,7 +576,7 @@
             "归档目录必须落在 openspec/changes/archive/YYYY-MM-DD-<change-id>/，不能改到其它位置。"
           ],
           "blocked_when": [
-            "缺少 proposal/specs/design/tasks/checklist/iterations 任一关键产物时，不得执行归档。"
+            "缺少 proposal/specs/tasks/checklist/iterations 任一关键产物时，不得执行归档。"
           ]
         }
       },
@@ -601,7 +591,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks",
         "checklist",
         "iterations"
@@ -831,7 +820,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []
@@ -973,7 +961,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []
@@ -1107,7 +1094,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []

package/.agents/roles/common/backend-implementer.md

@@ -16,7 +16,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - code
@@ -35,13 +34,13 @@ handoff_to:
 
 ## 工作原则
 
-- 先读 `proposal.md`、`specs/`、`design.md` 和 `tasks.md`，再动代码
+- 先读 `proposal.md`、`specs/` 和 `tasks.md`，再动代码
 - 若当前 flow 是 `bugfix-to-verification`，优先读 `bugfix.md`、用户原始输入和仓库规则，再做最小修复
 - 先按分层规范（Controller → Service → Repository）判断实现落点，再选技能
 - 项目规则高于 skill 示例；如果 skill 样例与当前项目约定冲突，以规则为准
 - 优先复用现有服务、Repository 和工具类，不重复建设
 - 修改范围尽量贴近本次变更，不顺手大改无关代码
-- 若 `proposal.md`、`specs/`、`design.md` 或 `tasks.md` 缺失，必须退回要求补齐
+- 若 `proposal.md`、`specs/` 或 `tasks.md` 缺失，必须退回要求补齐
 
 ## 必做步骤
 
@@ -64,7 +63,7 @@ handoff_to:
 
 ### OpenSpec 模式
 
-- 输入以 `proposal.md / specs/ / design.md / tasks.md` 为准
+- 输入以 `proposal.md / specs/ / tasks.md` 为准
 - 输出以 `code + implementation-notes` 为准
 - 不得跳过需求收敛产物直接写实现
 

package/.agents/roles/common/code-guardian.md

@@ -18,7 +18,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - openspec/changes/<change-id>/checklist.md
@@ -37,7 +36,7 @@ handoff_to: []
 
 ## 工作原则
 
-- 以规则、specs/design、任务目标和验收标准为准
+- 以规则、specs、任务目标和验收标准为准
 - 若当前 flow 是 `bugfix-to-verification`，必须同时把 quick-fix 边界核查写进结论
 - 先建立需求完成度清单，再做规则与质量审查
 - 先发现问题，再判断严重程度和是否阻断交付
@@ -83,7 +82,7 @@ handoff_to: []
 
 ### OpenSpec 模式
 
-- 以 `proposal/specs/design/tasks` 和当前实现为主输入
+- 以 `proposal/specs/tasks` 和当前实现为主输入
 - 输出 `openspec/changes/<change-id>/checklist.md` 与 `iterations.md`
 - 继续承担归档前放行门禁
 

package/.agents/roles/common/frontend-implementer.md

@@ -22,7 +22,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - code
@@ -41,7 +40,7 @@ handoff_to:
 
 ## 工作原则
 
-- 先读 `proposal.md`、`specs/`、`design.md` 和 `tasks.md`，再动代码
+- 先读 `proposal.md`、`specs/` 和 `tasks.md`，再动代码
 - 若当前 flow 是 `bugfix-to-verification`，优先读 `bugfix.md`、用户原始输入和仓库规则，再做最小修复
 - 先按 `rules` 和 `repo_conventions` 判断目录、路由、API、状态、样式落点，再选 skill
 - 项目规则高于 skill 示例；如果 skill 样例与当前项目约定冲突，以规则为准
@@ -49,7 +48,7 @@ handoff_to:
 - 按技术栈选择对应 profile skill，不混用无关框架做法
 - 修改范围尽量贴近本次变更，不顺手大改无关代码
 - 若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构
-- 若 `proposal.md`、`specs/`、`design.md` 或 `tasks.md` 缺失，必须退回要求补齐，不能跳过需求阶段直接实现
+- 若 `proposal.md`、`specs/` 或 `tasks.md` 缺失，必须退回要求补齐，不能跳过需求阶段直接实现
 - 优先执行协议下发的 `project_context / repo_conventions / implementation_contract`
 - 实现方式必须由 `role_skill_contract` 和 `role_rule_contract` 共同约束，而不是自由发挥
 
@@ -77,7 +76,7 @@ handoff_to:
 
 ### OpenSpec 模式
 
-- 输入以 `proposal.md / specs/ / design.md / tasks.md` 为准
+- 输入以 `proposal.md / specs/ / tasks.md` 为准
 - 输出以 `code + implementation-notes` 为准
 - 不得跳过需求收敛产物直接写实现
 

package/.agents/roles/common/requirement-analyst.md

@@ -4,7 +4,7 @@ name: 需求解析专家
 status: active
 domains:
   - demand-design
-description: 负责把 PRD、设计稿或自然语言需求收敛为本次变更的 proposal、specs、design、tasks 和关键假设，作为实现前置输入。
+description: 负责把 PRD、设计稿或自然语言需求收敛为本次变更的 proposal、specs、tasks 和关键假设，作为实现前置输入。
 triggers:
   - prd-input
   - design-input
@@ -19,7 +19,6 @@ reads:
 writes:
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 handoff_to:
   - frontend-implementer
@@ -29,7 +28,7 @@ handoff_to:
 
 ## 角色定位
 
-负责把 PRD、设计稿或自然语言需求收敛成当前 change 的 `proposal.md / specs/ / design.md / tasks.md`。
+负责把 PRD、设计稿或自然语言需求收敛成当前 change 的 `proposal.md / specs/ / tasks.md`。
 
 它不写实现代码，也不替实现专家补需求边界；它的职责是把“想做什么”翻译成“按当前项目规则可以怎么做”。
 
@@ -52,8 +51,7 @@ handoff_to:
 4. 若输入包含设计稿、视觉还原或复杂交互，先调用 `design-analysis`
 5. 使用 `create-proposal` 生成或补全 `proposal.md`
 6. 生成增量规范 `specs/<domain>/spec.md`，必要时拆成多个 domain
-7. 生成 `design.md`，把目录、路由、接口、mock、状态、样式落点写清
-8. 生成 `tasks.md`，把关键规则约束转成可执行任务，而不是抽象建议
+7. 生成 `tasks.md`，把关键规则约束转成可执行任务，而不是抽象建议
 9. 列出关键假设、依赖项和待确认问题，并区分是否阻断实现
 10. 在 `openspec/changes/<change-id>/` 下落盘完成前，不得把本轮标记为 done
 
@@ -62,11 +60,11 @@ handoff_to:
 - 优先读取协议下发的 `project_context（项目事实）` 与 `repo_conventions（仓库约定）`
 - 按 `role_rule_contract` 理解当前项目允许的页面、路由、API、mock、样式落点
 - 按 `role_skill_contract.primary_skills` 决定先读哪个技能：
-  - `create-proposal` 负责 proposal/specs/design/tasks 的结构化产出
+  - `create-proposal` 负责 proposal/specs/tasks 的结构化产出
   - `design-analysis` 仅在存在 UI/页面结构需求时辅助梳理
-- 对于项目规则中已经明确的事实，应直接写入 proposal/specs/design/tasks 或 assumptions，而不是重复标为 missing_inputs
+- 对于项目规则中已经明确的事实，应直接写入 proposal/specs/tasks 或 assumptions，而不是重复标为 missing_inputs
 - 若 `rules` 与某个 skill 示例写法冲突，以当前项目规则与目录约定为准
-- 复杂交互场景下，应优先把搜索、表单、弹窗、批量操作等交互口径写成摘要，再写入 proposal / design / tasks
+- 复杂交互场景下，应优先把搜索、表单、弹窗、批量操作等交互口径写成摘要，再写入 proposal / tasks
 
 ## 输出标准
 
@@ -85,14 +83,6 @@ handoff_to:
 - 至少一个 domain；必要时可同时存在 `ui/`、`api/`、`runtime/` 等多个 domain
 - 每份 spec 至少包含一个可验证场景
 
-`design.md` 至少应包含：
-
-- 中文标题：实现落点、目录与模块组织、接口或状态承载方式、风险与取舍
-- 当前仓库中的目录/路由/API/状态/样式真实落点
-- 需要复用的现有结构与避免引入的无关重构
-- 与 specs 对应的实现边界和关键技术约束
-- 真实接口与 mock-first 的边界说明
-
 `tasks.md` 至少应包含：
 
 - 中文标题：任务清单
@@ -108,7 +98,6 @@ handoff_to:
 
 - `proposal.md` 使用短版：目标、范围、默认假设、风险
 - `specs/<domain>/spec.md` 使用短版：只写当前变更需要的增量规范与场景
-- `design.md` 使用短版：只保留真实实现落点与关键约束
 - `tasks.md` 使用短版：3-5 条可执行任务
 - 标题统一使用中文，不混入英文章节名
 - 仍需真实落盘，不允许省略
@@ -130,7 +119,7 @@ handoff_to:
 - 不直接跳过需求澄清进入编码
 - 不把显著风险写成“后续再看”
 - 不输出只有标题、没有约束和边界的空模板
-- 不在未生成 `proposal.md`、`specs/`、`design.md` 和 `tasks.md` 时宣称需求阶段完成
+- 不在未生成 `proposal.md`、`specs/` 和 `tasks.md` 时宣称需求阶段完成
 
 ## 交接
 

package/.agents/roles/common/tooling-implementer.md

@@ -16,7 +16,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - code
@@ -35,13 +34,13 @@ handoff_to:
 
 ## 工作原则
 
-- 先读 `proposal.md`、`specs/`、`design.md` 和 `tasks.md`，再动代码
+- 先读 `proposal.md`、`specs/` 和 `tasks.md`，再动代码
 - 若当前 flow 是 `bugfix-to-verification`，优先读 `bugfix.md`、用户原始输入和仓库规则，再做最小修复
 - 先按模块规范（CLI / Contract / Worker / Utils）判断实现落点，再选技能
 - 项目规则高于 skill 示例；如果 skill 样例与当前项目约定冲突，以规则为准
 - 优先复用现有工具函数、Contract 定义和模块导出，不重复建设
 - 修改范围尽量贴近本次变更，不顺手大改无关代码
-- 若 `proposal.md`、`specs/`、`design.md` 或 `tasks.md` 缺失，必须退回要求补齐
+- 若 `proposal.md`、`specs/` 或 `tasks.md` 缺失，必须退回要求补齐
 
 ## 必做步骤
 
@@ -64,7 +63,7 @@ handoff_to:
 
 ### OpenSpec 模式
 
-- 输入以 `proposal.md / specs/ / design.md / tasks.md` 为准
+- 输入以 `proposal.md / specs/ / tasks.md` 为准
 - 输出以 `code + implementation-notes` 为准
 - 不得跳过需求收敛产物直接写实现
 

package/.agents/rules/common/12-Superpowers/346/211/247/350/241/214/350/247/204/350/214/203.md

@@ -23,7 +23,7 @@ description: 实现变更时的强制执行规范，要求启用 Superpowers 微
 |------|------|----------|
 | 1 | 头脑风暴 | 先思考边界情况、错误处理和对现有代码的影响；有歧义必须提问 |
 | 2 | TDD 驱动 | RED → GREEN → REFACTOR；REFACTOR 阶段须按需引用 `.agents/rules/` 中的对应规范 |
-| 3 | 双重审查 | 设计对齐（`design.md` / `specs/`）+ 质量门禁（异常捕获、类型严谨）；**必须输出审查结论表格** |
+| 3 | 双重审查 | 设计对齐（`specs/`）+ 质量门禁（异常捕获、类型严谨）；**必须输出审查结论表格** |
 | 4 | 审计汇报 | 按 `14-审计汇报规范.md` 输出读取记录、操作记录、规范对齐、技能状态、偏差说明 |
 
 ## 何时可以跳过

package/.agents/rules/common/14-/345/256/241/350/256/241/346/261/207/346/212/245/350/247/204/350/214/203.md

@@ -33,13 +33,12 @@ description: 执行审计汇报规范，要求 AI 在产出代码变更后附带
 |------|---------|------|
 | 技能 | `.agents/skills/xxx/SKILL.md` | 已 Read / 未 Read |
 | 规则 | `.agents/rules/xxx.md` | 已 Read / 未 Read，依据 xxx 推断 |
-| 设计 | `openspec/changes/xxx/design.md` | 已 Read / 未 Read |
 | 任务 | `openspec/changes/xxx/tasks.md` | 已 Read |
 
 状态取值说明：
 
 - **已 Read**：本次对话中使用 Read 工具读取过该文件
-- **未 Read，依据 X 推断**：未直接读取，但依据其它已读文件（如 tasks.md、design.md）中的描述推断行为
+- **未 Read，依据 X 推断**：未直接读取，但依据其它已读文件（如 tasks.md、specs/）中的描述推断行为
 - **未 Read，凭既有知识**：未读取，依据训练知识或上下文惯例行事
 
 ### 区块 2：操作记录

package/.agents/rules/profiles/react/01-/351/241/271/347/233/256/346/246/202/350/277/260.md

@@ -22,7 +22,7 @@ description: 项目定位与技术栈概览。当需要了解项目背景、使
 | 状态管理 | Zustand ^5.0.8 | Zustand（推荐）或 Redux，详见 07-状态管理 |
 | 组件库 | Ant Design 6.1.0+ | 所有交互 UI 必须基于 Antd 二次封装 |
 | 样式方案 | SCSS Modules, classnames | 强制使用，禁止全局样式 |
-| HTTP 请求 | @koi-design/vix-tools (request) | 统一请求封装，详见 05-API规范 |
+| HTTP 请求 | 项目统一 request 工具（如 `@/utils/request`） | 统一请求封装，详见 05-API规范 |
 | 基础库 | @shentu/cli, @shentu/core | 脚手架与核心工具库 |
 | Hooks 工具 | ahooks 3.9.6 | 编写或封装 hooks 时，优先考虑是否有可使用的 ahooks |
 | 工具函数 | lodash-es 4.17.21 | 编写或封装 函数 时，优先考虑是否有可使用的 lodash 函数 |

package/.agents/rules/profiles/react/05-API/350/247/204/350/214/203.md

@@ -25,12 +25,12 @@ src/
 
 ## 接口请求规范
 
-- 使用 `@koi-design/vix-tools` 的 `request` 发起请求
+- 使用项目统一的 `request` 工具函数发起请求（如 `@/utils/request`）
 - 请求全局配置（超时、成功码、鉴权失败处理等）集中在 `src/config/requestConfig.ts`
 - 应用入口通过 `request.init(requestConfig)` 完成初始化
 
 ```ts
-import { request } from '@koi-design/vix-tools';
+import { request } from '@/utils/request';
 
 export function getOrderListApi(data: GetOrderListParams): Promise<GetOrderListResult> {
   return request({

package/.agents/rules/profiles/vue/05-API/350/247/204/350/214/203.md

@@ -25,12 +25,12 @@ src/
 
 ## 接口请求规范
 
-- 使用 `@koi-design/vix-tools` 的 `request` 发起请求
+- 使用项目统一的 `request` 工具函数发起请求（如 `@/utils/request`）
 - 请求全局配置（超时、成功码、鉴权失败处理等）集中在 `src/config/requestConfig.ts`
 - 应用入口通过 `request.init(requestConfig)` 完成初始化
 
 ```ts
-import { request } from '@koi-design/vix-tools';
+import { request } from '@/utils/request';
 
 export function getOrderListApi(data: GetOrderListParams): Promise<GetOrderListResult> {
   return request({

package/.agents/skills/common/archive-change/SKILL.md

@@ -59,7 +59,6 @@ compatibility: Requires an OpenSpec workspace with openspec/changes/, the local
 | 变更元数据 | `openspec/changes/<name>/.openspec.yaml` | 是 |
 | 提案文档 | `openspec/changes/<name>/proposal.md` | 是 |
 | 增量规范 | `openspec/changes/<name>/specs/` | 是 |
-| 技术设计 | `openspec/changes/<name>/design.md` | 是 |
 | 任务清单 | `openspec/changes/<name>/tasks.md` | 是 |
 
 检查 `tasks.md` 中的任务完成状态：