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

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`。
 
 它不写实现代码，也不替实现专家补需求边界；它的职责是把“想做什么”翻译成“按当前项目规则可以怎么做”。
 
@@ -44,6 +43,31 @@ handoff_to:
 - 输出必须服务后续实现与验收，不写空泛汇报材料
 - 专家不是发明新方案，而是通过 `rules + skills + OpenSpec` 收敛到当前项目可实施方案
 
+## 复杂度快速判断
+
+**简单需求（快速通道）** - 满足以下全部条件：
+- 单文件或 2-3 个文件的修改
+- 任务明确（如"加个按钮"、"改个样式"、"加个校验"）
+- 不涉及新模块、新路由、新接口
+- 无需设计稿或复杂交互
+- 项目规则中已有明确实现模式
+
+**快速通道行为**：
+1. 跳过 `design-analysis` 调用
+2. `proposal.md` 使用短版（目标、范围、假设，各 1-2 行）
+3. `specs/` 使用短版（只写变更点，不写完整场景）
+4. `tasks.md` 使用短版（3-5 条直接可执行任务）
+5. 直接进入实现，不做详细澄清
+
+**复杂需求（完整分析）** - 命中以下任一条件：
+- 涉及多个模块或系统级变更
+- 需要新接口、新状态管理、新路由设计
+- 有设计稿或复杂交互需求
+- 存在技术选型或架构决策
+- 规则不明确，需要大量澄清
+
+**完整分析行为**：按下方"必做步骤"执行完整流程。
+
 ## 必做步骤
 
 1. 读取任务输入、项目背景、`role_rule_contract`、`repo_conventions`
@@ -52,8 +76,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 +85,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 +108,6 @@ handoff_to:
 - 至少一个 domain；必要时可同时存在 `ui/`、`api/`、`runtime/` 等多个 domain
 - 每份 spec 至少包含一个可验证场景
 
-`design.md` 至少应包含：
-
-- 中文标题：实现落点、目录与模块组织、接口或状态承载方式、风险与取舍
-- 当前仓库中的目录/路由/API/状态/样式真实落点
-- 需要复用的现有结构与避免引入的无关重构
-- 与 specs 对应的实现边界和关键技术约束
-- 真实接口与 mock-first 的边界说明
-
 `tasks.md` 至少应包含：
 
 - 中文标题：任务清单
@@ -108,7 +123,6 @@ handoff_to:
 
 - `proposal.md` 使用短版：目标、范围、默认假设、风险
 - `specs/<domain>/spec.md` 使用短版：只写当前变更需要的增量规范与场景
-- `design.md` 使用短版：只保留真实实现落点与关键约束
 - `tasks.md` 使用短版：3-5 条可执行任务
 - 标题统一使用中文，不混入英文章节名
 - 仍需真实落盘，不允许省略
@@ -130,7 +144,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` 中的任务完成状态：

package/.agents/skills/common/create-proposal/SKILL.md

@@ -15,7 +15,7 @@ compatibility: Requires an OpenSpec workspace, local .agents/rules constraints,
 | 层 | 职责 | 产物位置 |
 |----|------|----------|
 | **本技能** | 需求前置分析 + 上下文注入 + 后置检查 | 无独立产物（分析结论注入 OpenSpec 上下文） |
-| **OpenSpec** | 生成 proposal.md / specs/ / design.md / tasks.md | `openspec/changes/<name>/` |
+| **OpenSpec** | 生成 proposal.md / specs/ / tasks.md | `openspec/changes/<name>/` |
 | **config.yaml** | 桥接 ai-spec-auto  规范到 OpenSpec rules | `openspec/config.yaml` |
 
 ## 使用时机
@@ -49,9 +49,9 @@ compatibility: Requires an OpenSpec workspace, local .agents/rules constraints,
 |------|------|------|
 | **是否有设计稿或 UI 要求描述** | 有 / 无 | 有 → 步骤 2 触发 design-analysis；OpenSpec 的 tasks 中应包含 UI 验收任务 |
 | **是否有接口（已提供或约定）** | 有 / 无 / 未就绪 | 有 → 正常对接；无 → 可不做数据层；未就绪 → mock，见项目 Mock 数据策略 |
-| **交付形态** | 新页面 / 功能组件 / 能力模块 / 其它 | 决定目录结构（routes vs components）与 OpenSpec design.md 中的技术方案 |
+| **交付形态** | 新页面 / 功能组件 / 能力模块 / 其它 | 决定目录结构（routes vs components）与 OpenSpec tasks.md 中的技术方案 |
 | **是否仅样式/还原类** | 是 / 否 | 是 → 重点在 design-analysis + 验收 |
-| **是否存在复杂交互** | 有 / 无 | 有 → 先按 `references/interaction-spec-template.md` 收口搜索、表单、弹窗、批量操作等交互说明，再写 proposal/design/tasks |
+| **是否存在复杂交互** | 有 / 无 | 有 → 先按 `references/interaction-spec-template.md` 收口搜索、表单、弹窗、批量操作等交互说明，再写 proposal/tasks |
 
 ---
 
@@ -62,9 +62,9 @@ compatibility: Requires an OpenSpec workspace, local .agents/rules constraints,
 - **使用技能**：`.agents/skills/design-analysis/SKILL.md`
 - **产出**：`docs/样式还原/<名称>-UI分析清单.md`
 
-分析清单应在 OpenSpec 生成提案前或同步完成，以便 OpenSpec 的 specs/、design.md、tasks.md 能引用分析结果。
+分析清单应在 OpenSpec 生成提案前或同步完成，以便 OpenSpec 的 specs/、tasks.md 能引用分析结果。
 
-若页面包含搜索、表单、弹窗、批量操作、复杂状态切换等交互，先参考 `references/interaction-spec-template.md` 把交互说明整理成摘要，再写入 `proposal.md / design.md / tasks.md`，避免实现阶段自己补口径。
+若页面包含搜索、表单、弹窗、批量操作、复杂状态切换等交互，先参考 `references/interaction-spec-template.md` 把交互说明整理成摘要，再写入 `proposal.md / tasks.md`，避免实现阶段自己补口径。
 
 ---
 
@@ -81,7 +81,6 @@ openspec/changes/<change-name>/
 ├── specs/              # Delta specs（新增/修改/删除的需求）
 │   └── <domain>/
 │       └── spec.md
-├── design.md           # 技术设计（方案选型、组件拆分、数据结构）
 └── tasks.md            # 实施任务清单
 ```
 
@@ -100,7 +99,7 @@ openspec/changes/<change-name>/
 
 OpenSpec 生成提案后，检查以下项目并按需补充：
 
-### 4.1 design.md 检查
+### 4.1 tasks.md 前置检查
 - 技术方案是否遵循 `.agents/rules/` 中的架构约束
 - 涉及页面时，是否参考了 `.agents/rules/06-路由规范.md`
 - 涉及组件时，是否参考了 `.agents/rules/04-组件规范.md`
@@ -150,7 +149,7 @@ OpenSpec 生成提案且本步骤 4 检查完毕后，**必须**以独立小节
 
 适合小改动或用户明确要求「快扫清单」、不强制每步输出四步标题时，提供**可复制**提示语：
 
-> 请直接按 `openspec/changes/<change-name>/tasks.md` 顺序逐项实现，每完成一项将对应 `- [ ]` 改为 `- [x]`，并保证与 `design.md`、`specs/` 一致。**凡产生代码变更**，仍须按 `.agents/rules/14-审计汇报规范.md` 输出审计报告，不得因未走 execute-task 四步而省略。
+> 请直接按 `openspec/changes/<change-name>/tasks.md` 顺序逐项实现，每完成一项将对应 `- [ ]` 改为 `- [x]`，并保证与 `specs/` 一致。**凡产生代码变更**，仍须按 `.agents/rules/14-审计汇报规范.md` 输出审计报告，不得因未走 execute-task 四步而省略。
 
 #### 4.5.4 可选说明
 

package/.agents/skills/common/execute-task/SKILL.md

@@ -44,7 +44,7 @@ metadata:
 ## 前置要求
 
 1. 当前工作区必须存在 `tasks.md` 文件，且包含未完成的任务 (`- [ ]`)。
-2. 必须已完整读取对应变更目录下的 `proposal.md` 或 `design.md` 获取上下文。
+2. 必须已完整读取对应变更目录下的 `proposal.md` 或 `specs/` 获取上下文。
 3. 必须已读取 `.agents/rules/12-Superpowers执行规范.md` 确认执行原则。
 4. 必须已读取 `.agents/rules/14-审计汇报规范.md` 确认审计报告格式。
 
@@ -111,7 +111,7 @@ metadata:
 
 | 维度 | 检查项 | 结论 |
 |------|--------|------|
-| 架构对齐 | 实现是否符合 `design.md` / `specs/` | 通过 / 偏差说明 |
+| 架构对齐 | 实现是否符合 `specs/` | 通过 / 偏差说明 |
 | 代码健壮性 | 异常捕获、类型严谨、边界处理 | 通过 / 待补充项 |
 | 规范合规 | 是否符合步骤 1 加载的规范 | 通过 / 偏差说明 |
 
@@ -124,7 +124,7 @@ metadata:
 
 | 维度 | 检查项 | 结论 |
 |------|--------|------|
-| 架构对齐 | 符合 design.md 组件拆分方案 | 通过 |
+| 架构对齐 | 符合 specs/ 组件拆分方案 | 通过 |
 | 代码健壮性 | Props 均有默认值，loading 防重复点击 | 通过 |
 | 规范合规 | 目录 PascalCase、barrel export（04-组件规范） | 通过 |
 ```

package/.agents/skills/profiles/react/create-api/SKILL.md

@@ -72,7 +72,7 @@ export type UpdateBannerParams = CreateBannerParams & { id: number };
 
 ```ts
 // src/api/banner.ts
-import { request } from '@koi-design/vix-tools';
+import { request } from '@/utils/request';
 import type {
   GetBannerListParams,
   GetBannerListResult,
@@ -140,6 +140,6 @@ const loadData = async () => {
 
 - [ ] 类型在 `src/api/types/<module>.ts`，请求在 `src/api/<module>.ts`？
 - [ ] 命名符合 `getXxxApi` / `createXxxApi` / `updateXxxApi` / `deleteXxxApi`？
-- [ ] 使用 `import { request } from '@koi-design/vix-tools'`？
+- [ ] 使用项目统一的 `request` 工具函数（如 `@/utils/request`）？
 - [ ] 未重复处理接口错误？
 - [ ] 类型与接口文档一致？

package/.agents/skills/profiles/vue/create-api/SKILL.md

@@ -51,7 +51,7 @@ export type UpdateBannerParams = CreateBannerParams & { id: number };
 
 ```ts
 // src/api/banner.ts
-import { request } from '@koi-design/vix-tools';
+import { request } from '@/utils/request';
 import type {
   GetBannerListParams,
   GetBannerListResult,
@@ -100,6 +100,6 @@ export function deleteBannerApi(id: number): Promise<void> {
 
 - [ ] 类型在 `src/api/types/<name>.ts`，请求在 `src/api/<name>.ts`？
 - [ ] 命名符合 `getXxxApi` / `createXxxApi` / `updateXxxApi` / `deleteXxxApi`？
-- [ ] 使用 `import { request } from '@koi-design/vix-tools'`？
+- [ ] 使用项目统一的 `request` 工具函数（如 `@/utils/request`）？
 - [ ] 未重复处理接口错误？
 - [ ] 类型与接口文档一致？