commit 0cce68b38c5d60129012a28bb7a5040e82f5b620 Author: 锦麟 王 Date: Mon Apr 27 17:45:20 2026 +0800 初始化自动化开发工作流技能库 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..2b341a1 --- /dev/null +++ b/.gitignore @@ -0,0 +1,16 @@ +# 系统文件 +.DS_Store +Thumbs.db + +# IDE +.vscode/ +.idea/ +*.swp +*.swo + +# 临时文件 +*.tmp +*.temp + +# 日志 +*.log diff --git a/README.md b/README.md new file mode 100644 index 0000000..4c049ee --- /dev/null +++ b/README.md @@ -0,0 +1,164 @@ +# 自动化开发工作流技能库 + +> 基于 Claude Code 的自动化开发全流程技能集合，覆盖需求 → 审核 → 设计 → TDD → 计划 → 开发 → 测试 → 交付的完整闭环。 + +## 技能清单 + +| 技能 | 指令 | 说明 | 阶段 | +|------|------|------|------| +| dev-workflow | `/dev-workflow` | 工作流总控，管理全流程进度 | 总控 | +| dev-requirement | `/dev-requirement` | 需求分析，产出需求文档 | 第 1 阶段 | +| dev-review | `/dev-review` | 需求审核，过滤无关/复杂需求 | 第 2 阶段 | +| dev-design | `/dev-design` | 技术设计与选型 | 第 3 阶段 | +| dev-tdd | `/dev-tdd` | 测试先行，生成测试骨架 | 第 4 阶段 | +| dev-plan | `/dev-plan` | 步骤分解，定义验收标准 | 第 5 阶段 | +| dev-develop | `/dev-develop` | 开发执行，让测试变绿 | 第 6 阶段 | +| dev-test | `/dev-test` | 测试验证，代码审核 | 第 7 阶段 | +| dev-deliver | `/dev-deliver` | 交付发布 + 反馈闭环 | 第 8 阶段 | + +## 安装方式 + +### 安装整个技能库 + +```bash +npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --all +``` + +### 安装单个技能 + +```bash +# 安装主控技能 +npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --skill dev-workflow + +# 安装需求分析技能 +npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --skill dev-requirement +``` + +### 全局安装（推荐） + +```bash +npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --all -g -y +``` + +## 快速开始 + +安装完成后，在项目目录中： + +```bash +# 启动工作流 +claude /dev-workflow + +# 或直接启动某个阶段 +claude /dev-requirement +``` + +## 权限配置 + +为获得最佳自动化体验，建议配置权限等级： + +```bash +# 开发模式：常用命令自动批准 +cp .claude/permissions/level-3-dev.json .claude/settings.json +``` + +## 工作流流程 + +``` +╔═════════════════════════════════════════════════════════════════════════╗ +║ 自动化开发工作流 ║ +╚═════════════════════════════════════════════════════════════════════════╝ + +┌───────────────┐ +│ 需求收集 │ /dev-requirement +│ 产出文档 │ docs/requirements/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 需求审核 │ /dev-review +│ 通过/拒绝/ │ docs/reviews/ +│ 上报决策 │ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 技术设计 │ /dev-design +│ 架构与选型 │ docs/design/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ TDD测试 │ /dev-tdd +│ 先行 │ docs/test-cases/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 步骤分解 │ /dev-plan +│ 验收标准 │ docs/plans/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 开发执行 │ /dev-develop +│ 让测试变绿 │ docs/dev-logs/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 测试验证 │ /dev-test +│ 审核+测试 │ docs/test-reports/ +└───────────────┘ + │ + ▼ +┌───────────────┐ +│ 交付发布 │ /dev-deliver +│ +反馈闭环 │ docs/deliverables/ +└───────────────┘ + │ + └──────────┐ + ▼ + ┌────────────┐ + │ 人工反馈 │ + │ 驱动迭代 │ + └────────────┘ +``` + +## 更新技能 + +```bash +# 更新本库所有技能 +npx skills update workFlowSkill -y + +# 检查是否有更新 +npx skills check +``` + +## 目录结构 + +``` +workFlowSkill/ +├── README.md +├── .gitignore +├── dev-workflow/SKILL.md # 工作流总控 +├── dev-requirement/SKILL.md # 需求分析 +├── dev-review/SKILL.md # 需求审核 +├── dev-design/SKILL.md # 技术设计 +├── dev-tdd/SKILL.md # TDD测试先行 +├── dev-plan/SKILL.md # 步骤分解 +├── dev-develop/SKILL.md # 开发执行 +├── dev-test/SKILL.md # 测试验证 +└── dev-deliver/SKILL.md # 交付发布 +``` + +## 外部工具占位（后续接入） + +| 功能 | 当前占位 | 后续替换 | +|------|---------|---------| +| 工单状态同步 | `docs/processed-requirements.md` | 工单系统 API | +| 上报决策人 | `docs/reviews/pending/` | 邮件 MCP / Webhook | +| 定时触发 | 无 | 外部脚本 + Claude CLI | + +## License + +MIT diff --git a/dev-deliver/SKILL.md b/dev-deliver/SKILL.md new file mode 100644 index 0000000..9c0bd5c --- /dev/null +++ b/dev-deliver/SKILL.md @@ -0,0 +1,219 @@ +--- +name: dev-deliver +description: 开发流程 - 交付阶段，生成接口文档、使用文档、部署文档等交付物 +--- + +# 交付 + +> 开发流程第六阶段：基于实际代码和文档生成交付文档。 + +## 调用方式 + +`/dev-deliver`，也可说"生成交付文档"或"准备交付"。 + +## 产出目录 + +`docs/deliverables/` + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取所有前序产出物 +- [ ] 生成接口文档 +- [ ] 生成使用文档 +- [ ] 生成部署文档 +- [ ] 生成变更摘要 +- [ ] 用户审阅并保存 + +### 1. 前置检查 + +读取所有前序阶段的产出物： +- `docs/requirements/` — 需求文档 +- `docs/design/` — 设计文档 +- `docs/plans/` — 步骤计划 +- `docs/dev-logs/` — 开发日志 +- `docs/test-reports/` — 测试报告 + +如果某些阶段缺失，提示用户但不阻止执行。基于已有信息生成交付文档。 + +### 2. 生成接口文档 + +**基于实际代码扫描：** +- 读取项目源代码文件 +- 识别 API 端点、路由定义 +- 提取函数签名和参数 +- 识别请求/响应格式 +- 提取错误码定义 + +**生成格式：** + +```markdown +## 接口文档 + +### API 接口 N：<名称> + +**方法**：POST +**路径**：/api/xxx +**描述**：xxx + +**请求参数**： +| 参数 | 类型 | 必填 | 描述 | +|------|------|------|------| + +**响应格式**： +[实际响应结构] + +**错误码**： +| 错误码 | 描述 | +|--------|------| +``` + +如果项目不是 API/库类型，调整为文档对应的接口形式（函数接口、模块接口等）。 + +### 3. 生成使用文档 + +**基于项目配置文件：** +- 读取 package.json / pyproject.toml / Makefile 等 +- 识别依赖和版本要求 +- 提取安装/构建命令 +- 读取配置文件示例 + +**生成格式：** + +```markdown +## 使用文档 + +### 环境要求 +- Node.js >= 18 +- npm >= 9 + +### 安装 +[实际安装命令] + +### 配置 +[实际配置说明] + +### 基本用法 +[使用示例] +``` + +### 4. 生成部署文档 + +**基于项目结构和配置：** +- 识别部署相关文件（Dockerfile、docker-compose.yml 等） +- 提取环境变量定义 +- 识别外部依赖服务 +- 提取构建和部署命令 + +**生成格式：** + +```markdown +## 部署文档 + +### 环境变量 +| 变量名 | 必填 | 描述 | 默认值 | +|--------|------|------|--------| + +### 部署步骤 +1. xxx +2. yyy + +### 依赖服务 +- 数据库：xxx +- 缓存：xxx +``` + +### 5. 生成变更摘要 + +**基于需求文档和开发日志：** + +```markdown +## 变更摘要 + +### 新增 +- 功能 A（涉及文件：src/xxx.ts） + +### 修改 +- 功能 B 优化（涉及文件：src/yyy.ts） + +### 已知问题 +- [问题 1]：描述及临时解决方案 +``` + +### 6. 用户审阅 + +- 将完整交付文档展示给用户 +- 分段确认：接口文档 → 使用文档 → 部署文档 → 变更摘要 +- 收集反馈并修改 +- 循环直到用户确认 + +### 7. 保存文档 + +按以下格式保存完整交付文档： + +```markdown +# 交付文档：<项目名称> + +> 创建日期：YYYY-MM-DD +> 版本：1.0.0 +> 状态：已交付 + +## 1. 项目概览 +## 2. 接口文档 +## 3. 使用文档 +## 4. 部署文档 +## 5. 变更摘要 +``` + +保存到 `docs/deliverables/YYYY-MM-DD-<项目名>.md` + +### 8. 发布执行（可选） + +根据项目类型，询问用户是否需要执行发布操作： + +``` +是否执行发布操作？ +[1] git tag + push +[2] npm publish / docker push +[3] 跳过，仅保留文档 +``` + +如选择发布，协助用户执行对应的命令（通过 Bash tool），并记录操作日志。 + +### 9. 反馈收集（闭环） + +交付完成后，收集本轮开发的反馈： + +```markdown +## 反馈记录 + +> 对应交付：docs/deliverables/xxx.md +> 反馈日期：YYYY-MM-DD + +### 评分（1-5） +- 需求理解准确度： +- 实现符合预期度： +- 整体满意度： + +### 问题与优化点 +- [ ] 问题 1 +- [ ] 问题 2 + +### 是否启动新一轮迭代 +- [ ] 是 → 更新 workflow-status.md 为"需求分析"阶段 +- [ ] 否 → 标记流程结束 +``` + +保存到 `docs/feedback/YYYY-MM-DD-<项目名>.md`。 + +更新 `docs/workflow-status.md`： +- 如用户选择迭代：当前阶段 = "需求分析"，提示 `/dev-requirement` +- 如用户结束：状态 = "已完成" + +## 关键行为 + +- 接口文档必须基于实际代码，不凭空编造 +- 环境变量从代码中实际提取（搜索 process.env、os.environ 等） +- 部署步骤基于项目实际配置（Dockerfile、CI/CD 等） +- 如无法从代码提取，明确标注"需手动补充" diff --git a/dev-design/SKILL.md b/dev-design/SKILL.md new file mode 100644 index 0000000..0658c1f --- /dev/null +++ b/dev-design/SKILL.md @@ -0,0 +1,127 @@ +--- +name: dev-design +description: 开发流程 - 设计阶段，技术选型与细节设计，产出设计文档 +--- + +# 设计 + +> 开发流程第二阶段：基于需求文档进行技术选型和细节设计。 + +## 调用方式 + +`/dev-design`，也可说"开始设计"。 + +## 产出目录 + +`docs/design/` + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取需求文档 +- [ ] 探索现有代码库 +- [ ] 技术选型 +- [ ] 前端风格设计（如涉及） +- [ ] 细节设计循环 +- [ ] 用户确认并保存 + +### 1. 前置检查 + +- 读取 `docs/requirements/` 目录下的需求文档 +- 如果不存在，提示用户先运行 `/dev-requirement` 完成需求分析 +- 用户可选择跳过（直接进入设计） +- 展示需求文档摘要，确认设计范围 + +### 2. 探索现有代码库 + +- 查看项目文件结构 +- 识别现有技术栈（package.json、pyproject.toml 等） +- 了解现有架构模式 +- 识别可复用的模块和接口 + +### 3. 技术选型 + +识别需要做出的技术决策，逐个讨论： + +**规则：** +- 每个决策点提出 2-3 个方案 +- 说明每个方案的优缺点 +- 给出推荐方案和理由 +- 使用多选方式让用户选择 + +**常见决策点：** +- 框架选择 +- 数据库/存储方案 +- 状态管理方案 +- API 风格（REST/GraphQL/RPC） +- 认证方案 + +### 4. 前端风格设计（如涉及） + +如果项目涉及 UI： +- 询问视觉风格偏好 +- 确定配色方案、字体、间距规范 +- 确定组件库（如有） +- 确定布局模式 + +如果项目不涉及 UI，跳过此步骤。 + +### 5. 细节设计循环 + +按以下维度逐个展开设计，每个维度分段展示给用户确认： + +**模块划分：** +- 将系统拆分为职责单一的模块 +- 每个模块有清晰的边界和接口 + +**数据模型：** +- 核心数据结构定义 +- 数据关系 +- 存储方案 + +**接口设计：** +- 模块间接口 / API 端点 +- 输入输出规范 +- 错误码定义 + +**错误处理：** +- 异常场景识别 +- 错误处理策略 +- 边界情况处理 + +### 6. 保存设计文档 + +按以下模板保存： + +```markdown +# 设计文档：<项目名称> + +> 创建日期：YYYY-MM-DD +> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md +> 状态：已确认 + +## 1. 技术选型 +| 决策点 | 选择 | 理由 | 备选方案 | +|-------|------|------|---------| + +## 2. 架构设计 +### 整体架构 +### 模块划分 +| 模块 | 职责 | 依赖 | +|------|------|------| + +## 3. 数据模型 +## 4. 接口设计 +## 5. 前端设计（如适用） +## 6. 错误处理与边界情况 +``` + +保存为 `docs/design/YYYY-MM-DD-<项目名>.md`，提示下一步可调用 `/dev-tdd` 生成测试用例（测试先行）。 + +## 关键行为 + +- 技术选型基于项目实际约束，不盲目追求新技术 +- 设计文档中的每个需求都能追溯到需求文档 +- 前端风格仅在涉及 UI 时展开 +- 模块划分遵循单一职责原则 diff --git a/dev-develop/SKILL.md b/dev-develop/SKILL.md new file mode 100644 index 0000000..3fccc88 --- /dev/null +++ b/dev-develop/SKILL.md @@ -0,0 +1,132 @@ +--- +name: dev-develop +description: 开发流程 - 开发执行阶段，按步骤执行开发并逐条验证验收标准 +--- + +# 开发执行 + +> 开发流程第四阶段：按步骤计划执行开发，每步完成后验证验收标准。 + +## 调用方式 + +`/dev-develop`，也可说"开始开发"。 + +支持指定步骤：`/dev-develop 步骤3` 或 `/dev-develop 3` + +## 产出目录 + +`docs/dev-logs/` + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取步骤计划 +- [ ] 读取/创建开发日志 +- [ ] 步骤执行循环（对每个步骤） +- [ ] 生成完整开发日志 + +### 1. 前置检查 + +- 读取 `docs/plans/` 目录下的步骤计划 +- 如果不存在，提示用户先运行 `/dev-plan`（用户可选择跳过，直接开始开发） +- 展示步骤概览和进度 + +### 2. 读取/创建开发日志 + +- 检查 `docs/dev-logs/` 是否已有本次开发日志 +- 如果有：读取进度，从未完成的步骤继续 +- 如果没有：创建新的开发日志 + +开发日志格式： + +```markdown +# 开发日志：<项目名称> + +> 创建日期：YYYY-MM-DD +> 对应计划：docs/plans/YYYY-MM-DD-xxx.md +> 状态：进行中 + +## 进度概览 + +| # | 步骤 | 状态 | 完成时间 | +|---|------|------|---------| +| 1 | xxx | ✅ 已完成 | HH:MM | +| 2 | yyy | 🔄 进行中 | - | +| 3 | zzz | ⏳ 待执行 | - | + +--- + +## 步骤 N：xxx + +**开始时间**：HH:MM +**完成时间**：HH:MM + +**执行内容**： +- 创建了 src/xxx.ts +- 修改了 src/yyy.ts + +**验收结果**： +- [x] 标准 1：通过（附验证命令输出） +- [x] 标准 2：通过 + +**备注**： +[任何偏离计划的情况] +``` + +### 3. 步骤执行循环 + +对每个待执行的步骤： + +**3a. 展示步骤详情** +- 展示当前步骤的目标、具体任务和验收标准 +- 确认用户准备开始 + +**3b. 执行开发任务** +- 按步骤计划中的任务项逐一执行 +- 编写/修改代码，保持简洁 +- 不添加计划之外的功能 + +**3c. 自动运行检查** +- 检查是否有 lint 配置，有则运行 +- 检查是否有 type check 配置，有则运行 +- 检查是否有 build 命令，有则运行 +- 运行现有测试（如有） +- 如果检查失败，修复后重新运行 + +**3d. 逐条验证验收标准** +- 对照步骤计划中的每条验收标准 +- 展示每条标准的验证方式和结果 +- 对于命令行验证：展示命令输出 +- 对于文件检查：展示文件内容 +- 对于功能验证：描述验证过程 + +**3e. 用户确认** +- 展示所有验收标准的验证结果 +- 询问用户是否确认通过 +- **通过**：标记步骤完成，更新开发日志，进入下一步 +- **未通过**：根据反馈修复，重新验证，回到 3d + +### 4. 完成开发日志 + +所有步骤完成后： +- 更新开发日志状态为"已完成" +- 记录总体完成时间 +- 保存到 `docs/dev-logs/YYYY-MM-DD-<项目名>.md` +- 提示下一步可调用 `/dev-test` 进行测试 + +## 断点续做 + +如果开发中途退出（会话结束），下次启动 `/dev-develop` 时： +- 自动读取开发日志 +- 识别最后一个"进行中"的步骤 +- 询问用户是从该步骤重新开始，还是继续下一步 +- 支持用户指定任意步骤：`/dev-develop 3` + +## 关键行为 + +- 每个步骤开始前明确展示目标，不盲目动手 +- 验收标准逐条核对，不自评"通过" +- 用户确认后才进入下一步，不跳过 +- 遇到问题及时反馈，不强行继续 +- 代码修改保持简洁，不添加计划外的增强 diff --git a/dev-plan/SKILL.md b/dev-plan/SKILL.md new file mode 100644 index 0000000..18c70e4 --- /dev/null +++ b/dev-plan/SKILL.md @@ -0,0 +1,123 @@ +--- +name: dev-plan +description: 开发流程 - 步骤分解阶段，将设计拆解为可验证的实施步骤 +--- + +# 步骤分解 + +> 开发流程第三阶段：将设计拆解为可验证的实施步骤，每步提供验收标准。 + +## 调用方式 + +`/dev-plan`，也可说"分解步骤"或"制定开发计划"。 + +## 产出目录 + +`docs/plans/` + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取需求和设计文档 +- [ ] 分析设计，识别实现步骤 +- [ ] 定义每个步骤的验收标准 +- [ ] 展示完整步骤列表 +- [ ] 用户确认并保存 + +### 1. 前置检查 + +- 读取 `docs/requirements/` 和 `docs/design/` +- 如果任一目录为空，提示用户先完成对应阶段（可选择跳过） +- 展示需求和设计摘要，确认分解范围 + +### 2. 分析设计，识别步骤 + +基于设计文档的模块划分和架构，将实现工作拆解为步骤。 + +**拆解原则：** +- 每个步骤必须**可独立验证** +- 步骤粒度：一个步骤应能在一次开发会话中完成 +- 优先按依赖关系排序：基础模块先于上层模块 +- 同一模块的相关任务归为同一步骤 + +### 3. 定义验收标准 + +为每个步骤定义验收标准。 + +**验收标准要求：** +- **可客观判断**：能通过命令执行、文件检查或视觉确认 +- **具体明确**：不使用"基本完成"、"大致可用"等模糊描述 +- **可演示**：每个步骤完成后都能展示具体成果 + +**好的验收标准示例：** +``` +- [ ] 执行 `npm run build` 无错误 +- [ ] 访问 /api/users 返回 200 和用户列表 JSON +- [ ] 用户可以点击"添加"按钮并在列表中看到新条目 +``` + +**不好的验收标准示例：** +``` +- [ ] 基本功能可用 +- [ ] 接口设计完成 +``` + +### 4. 展示步骤列表 + +按以下格式展示完整计划： + +```markdown +# 实施计划：<项目名称> + +> 创建日期：YYYY-MM-DD +> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md +> 对应设计：docs/design/YYYY-MM-DD-xxx.md +> 状态：待执行 + +## 步骤概览 + +| # | 步骤名称 | 依赖 | 状态 | +|---|---------|------|------| +| 1 | xxx | 无 | 待执行 | + +--- + +## 步骤 N：<标题> + +**目标**：一句话描述 + +**具体任务**： +- [ ] 任务项 1 +- [ ] 任务项 2 + +**验收标准**： +- [ ] 标准 1（可验证描述） +- [ ] 标准 2 + +**涉及文件**： +- src/xxx.ts（新建/修改） + +**预估复杂度**：低/中/高 + +--- + +## 依赖关系图 + +步骤 1 → 步骤 2, 3 → 步骤 4 +``` + +### 5. 用户确认 + +- 展示完整步骤列表 +- 询问是否需要调整（合并、拆分、重排序） +- 修改后循环展示直到用户确认 +- 保存为 `docs/plans/YYYY-MM-DD-<项目名>.md` +- 提示下一步可调用 `/dev-develop` 开始开发 + +## 关键行为 + +- 验收标准是步骤分解的核心，必须可验证 +- 步骤之间依赖关系必须明确，无循环依赖 +- 不遗漏设计文档中的任何模块或接口 +- 步骤数量适中（通常 3-10 个），避免过度拆分 diff --git a/dev-requirement/SKILL.md b/dev-requirement/SKILL.md new file mode 100644 index 0000000..63eb8de --- /dev/null +++ b/dev-requirement/SKILL.md @@ -0,0 +1,125 @@ +--- +name: dev-requirement +description: 开发流程 - 需求分析阶段，通过探讨和澄清循环产出需求文档 +--- + +# 需求分析 + +> 开发流程第一阶段：通过探讨 → 产出 → 澄清循环，产出满意的需求文档。 + +## 调用方式 + +`/dev-requirement` 或 `/dev-req`，也可说"开始需求分析"。 + +支持传入需求来源：`/dev-requirement docs/idea.md` 或 `/dev-requirement Issue#42`。 + +## 产出目录 + +`docs/requirements/` + +## 执行流程 + +### Checklist + +- [ ] 探索项目上下文 +- [ ] 收集原始需求 +- [ ] 探讨循环（澄清问题） +- [ ] 产出需求文档 +- [ ] 用户确认并保存 + +### 1. 探索项目上下文 + +启动后首先了解当前项目状态： + +- 读取项目根目录的文件结构 +- 查看现有文档（README、CLAUDE.md 等） +- 查看最近的 git 提交（如有） +- 查看是否已有 `docs/requirements/` 目录下的需求文档 + +### 2. 收集原始需求 + +根据用户输入获取需求来源： + +- 如果传入文件路径，读取该文件作为原始需求 +- 如果传入 Issue 编号，尝试读取 Issue 内容 +- 如果无参数，询问用户描述需求 + +### 3. 探讨循环 + +参考 superpowers:brainstorming 的核心模式： + +**规则：** +- 一次只问一个澄清问题 +- 优先使用多选选项向用户提问 +- 提出 2-3 个方案供选择时，说明权衡和推荐 +- YAGNI 原则：主动去掉不必要的需求 +- 不要自作主张添加用户没提到的需求 + +**探讨内容：** +- 业务背景和目标 +- 用户角色和使用场景 +- 核心功能需求 +- 非功能需求（性能、安全等） +- 约束和假设 +- 范围边界（包含/不包含） + +**退出条件：** 你已充分理解以下内容： +- 为什么做这个项目 +- 谁是目标用户 +- 核心功能有哪些 +- 成功标准是什么 + +### 4. 产出需求文档 + +按以下模板生成需求文档，分段展示给用户审阅： + +```markdown +# 需求文档：<项目名称> + +> 创建日期：YYYY-MM-DD +> 状态：已确认 + +## 1. 背景与目标 +### 业务背景 +### 核心目标 +### 成功指标 + +## 2. 功能需求 +（每个需求用用户故事格式） +### 用户故事 N +**作为** [角色]，**我想要** [功能]，**以便** [价值] +验收条件： +- [ ] 条件 1 + +## 3. 非功能需求 +- 性能： +- 安全： +- 兼容性： +- 可维护性： + +## 4. 约束与假设 +### 技术约束 +### 业务假设 + +## 5. 范围说明 +### 包含 +### 不包含 +``` + +**审阅规则：** +- 每展示一段后询问是否满意 +- 收集反馈后修改，进入下一轮展示 +- 循环直到用户确认整体满意 + +### 5. 保存文档 + +- 确保 `docs/requirements/` 目录存在 +- 保存为 `docs/requirements/YYYY-MM-DD-<项目名>.md` +- 告知用户文件位置，提示下一步可调用 `/dev-review` 进行需求审核 + +## 关键行为 + +- 探讨阶段不急躁，确保充分理解后再产出 +- 产出时不遗漏探讨中确认的任何需求点 +- 文档中的每个需求都有对应的验收条件 +- 范围说明中的"不包含"要明确列出并说明原因 diff --git a/dev-review/SKILL.md b/dev-review/SKILL.md new file mode 100644 index 0000000..3af43b7 --- /dev/null +++ b/dev-review/SKILL.md @@ -0,0 +1,218 @@ +--- +name: dev-review +description: 开发流程 - 需求审核阶段，评估需求相关性、复杂度与可行性，决定推进、拒绝或上报决策 +--- + +# 需求审核 + +> 开发流程第二阶段：审核需求的相关性、复杂度与可行性，过滤无关需求，拦截复杂/高风险需求上报决策。 + +## 调用方式 + +`/dev-review`，也可说"审核需求"。 + +## 产出目录 + +`docs/reviews/`（审核通过的记录） +`docs/reviews/pending/`（待决策的审核记录） + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取需求文档 +- [ ] 相关性评估 +- [ ] 复杂度评估 +- [ ] 可行性评估 +- [ ] 生成审核结论 +- [ ] 更新状态（避免重复触发） +- [ ] 上报决策人（如需要，外部工具占位） + +### 1. 前置检查 + +- 读取 `docs/requirements/` 目录下最新的需求文档 +- 读取 `docs/processed-requirements.md` 已处理需求清单（如存在） +- 检查该需求是否已在处理中或已处理，避免重复审核 +- 如未找到需求文档，提示用户先运行 `/dev-requirement` + +### 2. 相关性评估 + +判断需求是否属于本系统的业务范围。 + +**评估标准：** +- 需求的功能领域是否在本系统职责范围内 +- 是否涉及本系统已有模块的合理扩展 +- 是否属于本团队/项目的维护范围 + +**结论：** +- **相关** → 继续下一步评估 +- **无关** → 直接拒绝，记录原因 + +### 3. 复杂度评估 + +评估需求的技术实现复杂度。 + +| 等级 | 判断标准 | 处理方式 | +|------|---------|---------| +| 简单 | 现有模式直接套用，无新架构 | 直接通过 | +| 中等 | 需要新模块或接口设计，但技术路径清晰 | 直接通过 | +| 复杂 | 涉及架构变更、跨系统协调、性能敏感场景 | 标记需决策 | + +**触发"需决策"的典型情况：** +- 需要引入新的技术栈或基础设施 +- 涉及大量数据迁移或兼容性问题 +- 需要与其他团队/系统协调接口 +- 性能要求超出当前架构能力 +- 安全合规风险较高 + +### 4. 可行性评估 + +检查需求在当前约束下是否可行。 + +**评估维度：** +- **技术约束**：现有技术栈是否支持 +- **资源约束**：人力、时间是否足够 +- **依赖约束**：是否依赖外部系统/团队 +- **合规约束**：是否符合安全/合规要求 + +### 5. 生成审核结论 + +三种结论，只能有一种： + +#### A. 通过 + +需求属于本系统范围，复杂度在可控范围内，可直接进入设计阶段。 + +**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md` + +```markdown +# 需求审核报告 + +> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md +> 审核日期：YYYY-MM-DD + +## 审核结论：通过 + +## 评估详情 +### 相关性：相关 +[说明] + +### 复杂度：简单/中等 +[说明] + +### 可行性：可行 +[说明] + +## 建议下一步 +进入设计阶段：`/dev-design` +``` + +#### B. 拒绝 + +需求与本系统无关，或技术上不可行。 + +**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md` + +```markdown +# 需求审核报告 + +## 审核结论：拒绝 + +## 拒绝原因 +- 原因 1 +- 原因 2 + +## 建议 +[转交给哪个系统/团队，或建议用户如何调整] +``` + +**操作：** +- 将需求标记为"已拒绝" +- 更新 `docs/processed-requirements.md` +- 告知用户流程终止，不进入后续阶段 + +#### C. 需决策 + +需求相关但复杂度过高或存在不确定性，需要上报决策人评估。 + +**产出：** `docs/reviews/pending/YYYY-MM-DD-<项目名>-pending.md` + +```markdown +# 待决策需求上报 + +> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md +> 审核日期：YYYY-MM-DD + +## 需决策事项 + +| # | 问题 | 影响 | 建议方案 | +|---|------|------|---------| +| 1 | 涉及架构变更 | 影响现有模块 A、B | 方案 X / 方案 Y | +| 2 | 需要跨团队协作 | 依赖团队 C 的接口 | 先协调再排期 | + +## 复杂度评估 +[详细说明] + +## 推荐决策 +[给出倾向性建议] +``` + +### 6. 更新状态（避免重复触发） + +**当前实现（文件占位）：** + +更新 `docs/processed-requirements.md`： + +```markdown +# 已处理需求清单 + +| 需求文件 | 审核结论 | 状态 | 处理日期 | +|---------|---------|------|---------| +| YYYY-MM-DD-xxx.md | 通过 | 处理中 | YYYY-MM-DD | +| YYYY-MM-DD-yyy.md | 拒绝 | 已关闭 | YYYY-MM-DD | +| YYYY-MM-DD-zzz.md | 需决策 | 待决策 | YYYY-MM-DD | +``` + +**后续替换（外部工具接入时）：** + +``` +# TODO: 接入工单系统 API +# - 通过的工单：调用 set_status(ticket_id, "处理中") +# - 拒绝的工单：调用 set_status(ticket_id, "已拒绝") +# - 需决策的工单：调用 set_status(ticket_id, "待决策") +``` + +### 7. 上报决策人（外部工具占位） + +对于"需决策"的需求，当前流程： + +1. 生成 `docs/reviews/pending/xxx-pending.md` +2. 展示给用户，说明需要上报的内容 +3. **提示用户手动转发给决策人** + +**后续替换（外部工具接入时）：** + +``` +# TODO: 接入通知渠道 +# 方案 A：邮件 MCP server +# - 调用 send_email(decision_maker, subject, content) +# 方案 B：企业微信/钉钉 Webhook +# - 调用 send_webhook(url, message) +# 方案 C：工单系统内置通知 +# - 调用 add_comment(ticket_id, "@决策人 请审核") +``` + +## 流转规则 + +| 审核结论 | 下一步 | 状态 | +|---------|--------|------| +| 通过 | `/dev-design` | 处理中 | +| 拒绝 | 流程终止 | 已关闭 | +| 需决策 | 等待外部反馈，之后重新 `/dev-review` | 待决策 | + +## 关键行为 + +- 审核不通过时明确说明原因，给出替代建议 +- "需决策"不是拒绝，而是暂停等待更多信息 +- 每次审核都记录到 `processed-requirements.md`，确保不重复处理 +- 用户可覆盖审核结论（强制推进），但记录覆盖原因 diff --git a/dev-tdd/SKILL.md b/dev-tdd/SKILL.md new file mode 100644 index 0000000..fa33e1c --- /dev/null +++ b/dev-tdd/SKILL.md @@ -0,0 +1,169 @@ +--- +name: dev-tdd +description: 开发流程 - TDD 测试先行阶段，基于设计文档生成测试骨架，实现测试驱动开发 +--- + +# TDD 测试先行 + +> 开发流程第四阶段：基于设计文档生成测试骨架，先写测试再写实现，确保验收标准可量化。 + +## 调用方式 + +`/dev-tdd`，也可说"生成测试用例"或"TDD"。 + +## 产出目录 + +`docs/test-cases/`（测试用例设计文档） +项目源码中的测试文件（`.test.ts` / `.spec.ts` / `_test.py` 等） + +## 执行流程 + +### Checklist + +- [ ] 前置检查：读取需求和设计文档 +- [ ] 检测项目测试框架 +- [ ] 按模块识别测试点 +- [ ] 生成测试用例文档 +- [ ] 生成测试代码骨架（空实现 / 先失败） +- [ ] 验证测试可运行且初始状态为失败 +- [ ] 用户确认 + +### 1. 前置检查 + +- 读取 `docs/requirements/` 需求文档 +- 读取 `docs/design/` 设计文档（模块划分、接口定义、数据模型） +- 如果设计文档不存在，提示用户先运行 `/dev-design`（可选择跳过，基于需求直接生成） +- 展示设计摘要，确认测试生成范围 + +### 2. 检测项目测试框架 + +自动检测项目使用的测试框架： + +| 语言 | 检测方式 | 常用框架 | +|------|---------|---------| +| JavaScript/TypeScript | package.json devDependencies | jest, vitest, mocha, playwright | +| Python | pyproject.toml / requirements.txt | pytest, unittest | +| Java | pom.xml / build.gradle | JUnit, TestNG | +| Go | go.mod | testing, testify | +| Rust | Cargo.toml | 内置 test | + +如果没有检测到测试框架： +- 询问用户是否安装（推荐 Vitest 或 Jest 用于 JS/TS，pytest 用于 Python） +- 如用户拒绝，生成 `docs/test-cases/` 下的纯文本测试用例文档，不生成代码 + +### 3. 按模块识别测试点 + +基于设计文档的模块划分，为每个模块识别测试点： + +**每个模块的测试点维度：** +- **正常路径**：标准输入下的预期输出 +- **边界情况**：空值、最大值、最小值、空数组等 +- **错误路径**：异常输入、权限不足、网络失败等 +- **状态转换**：涉及状态机的模块，各状态转换路径 + +### 4. 生成测试用例文档 + +为每个模块生成测试用例设计文档，保存到 `docs/test-cases/`： + +```markdown +# 测试用例设计：<模块名> + +> 对应设计：docs/design/xxx.md +> 对应模块：模块 A + +## 测试用例 1：正常路径 - [简短描述] + +**目标**：验证标准场景下的正确行为 +**输入**：[具体值或描述] +**预期输出**：[具体值或描述] +**涉及接口**：[函数/端点名] +**优先级**：高 + +## 测试用例 2：边界情况 - [简短描述] + +**目标**：验证边界输入的处理 +**输入**：[边界值] +**预期输出**：[预期行为] +**优先级**：中 + +## 测试用例 3：错误路径 - [简短描述] + +**目标**：验证异常情况的处理 +**输入**：[异常输入] +**预期输出**：[错误码/异常类型] +**优先级**：中 +``` + +### 5. 生成测试代码骨架 + +基于检测到的测试框架，生成实际的测试代码文件： + +**原则：** +- 每个测试用例对应一个测试函数 +- 测试函数名清晰描述场景：`should_xxx_when_xxx` +- 导入被测模块（根据设计文档中的接口定义） +- 使用 `todo()` 或 `skip()` 标记尚未实现的测试，或先写失败的断言 +- 不编写被测模块的实现代码 + +**示例（Vitest / TypeScript）：** + +```typescript +// src/modules/user/user.service.test.ts +import { describe, it, expect } from 'vitest' +import { UserService } from './user.service' + +describe('UserService', () => { + describe('创建用户', () => { + it('should create user with valid input', () => { + // TODO: 实现测试 + // const service = new UserService() + // const result = service.create({ name: '张三', email: 'zs@example.com' }) + // expect(result.name).toBe('张三') + expect(true).toBe(false) // 初始状态：失败 + }) + + it('should reject empty name', () => { + // TODO: 实现测试 + expect(true).toBe(false) // 初始状态：失败 + }) + }) +}) +``` + +### 6. 验证测试可运行且失败 + +生成测试后： +- 运行测试框架（如 `npm test` / `pytest`） +- 确认测试可以被识别并执行 +- 确认测试当前状态为**失败**（红） +- 如测试无法运行，修复配置问题（路径、导入、框架设置等） + +### 7. 用户确认 + +- 展示生成的测试用例文档摘要 +- 展示测试代码骨架的关键部分 +- 展示测试运行结果（确认是失败的） +- 询问用户是否满意，或需要补充/修改测试场景 +- 修改后循环直到确认 + +## 流转规则 + +生成完成后，提示下一步： +- `/dev-plan` — 将开发工作拆解为步骤（推荐） +- `/dev-develop` — 直接进入开发，让测试变绿 + +## 关键行为 + +- 测试用例必须能追溯到设计文档中的接口定义 +- 测试初始状态必须为失败（红），不允许一开始就通过 +- 不编写被测模块的实现代码，只写测试 +- 测试函数名使用描述性语言，不依赖注释解释场景 +- 如果设计文档中的接口不明确，先回到 `/dev-design` 澄清 + +## TDD 原则提醒 + +1. **红**：先写一个失败的测试 +2. **绿**：写最小代码让测试通过 +3. **重构**：优化代码，保持测试通过 + +本阶段只负责第 1 步（红）。第 2-3 步在 `/dev-develop` 中完成。 diff --git a/dev-test/SKILL.md b/dev-test/SKILL.md new file mode 100644 index 0000000..ba020d8 --- /dev/null +++ b/dev-test/SKILL.md @@ -0,0 +1,182 @@ +--- +name: dev-test +description: 开发流程 - 测试阶段，包括代码审核、单模块测试和全流程测试 +--- + +# 测试 + +> 开发流程第五阶段：代码审核 + 单模块测试 + 全流程测试。 + +## 调用方式 + +`/dev-test`，也可说"开始测试"。 + +## 产出目录 + +`docs/test-reports/` + +## 执行流程 + +### 启动时选择 + +展示测试范围选择： + +``` +请选择测试范围： + +[1] 完整测试流程（代码审核 → 模块测试 → 全流程测试） +[2] 仅代码审核 +[3] 仅模块测试 +[4] 仅全流程测试 +``` + +使用多选方式让用户选择。 + +### Checklist + +- [ ] 前置检查：读取计划和开发日志 +- [ ] 阶段 A：代码审核（如选择） +- [ ] 阶段 B：单模块测试（如选择） +- [ ] 阶段 C：全流程测试（如选择） +- [ ] 生成测试报告 + +### 前置检查 + +- 读取 `docs/plans/` 和 `docs/dev-logs/` +- 确认开发已全部完成（所有步骤状态为"已完成"） +- 如果未完成，提示用户先运行 `/dev-develop` 完成剩余步骤 +- 用户可选择跳过（对已完成部分进行测试） + +### 阶段 A：代码审核 + +#### A1. 确定审核范围 + +- 从开发日志中提取所有修改/新建的文件列表 +- 展示给用户确认 + +#### A2. 逐文件审核 + +对每个文件检查以下维度： + +| 维度 | 检查内容 | +|------|---------| +| 安全性 | SQL 注入、XSS、命令注入、敏感信息泄露等 OWASP Top 10 | +| 性能 | N+1 查询、内存泄漏、不必要的同步操作、大数据量处理 | +| 代码规范 | 命名一致性、函数长度、代码重复 | +| 设计符合度 | 对照设计文档，检查实现是否符合设计 | +| 边界情况 | 空值处理、错误路径、并发场景 | + +#### A3. 审核报告 + +产出审核结果： + +```markdown +## 代码审核详情 + +### 审核文件列表 +- src/xxx.ts +- src/yyy.ts + +### 发现问题 + +| # | 文件 | 行号 | 严重度 | 描述 | 状态 | +|---|------|------|--------|------|------| +| 1 | xxx.ts | 42 | 高 | SQL 注入风险 | ⏳ 待修复 | +``` + +#### A4. 用户确认修复 + +- 展示审核发现的问题 +- 与用户确认哪些需要修复 +- 执行修复 +- 修复后重新验证 + +### 阶段 B：单模块测试 + +#### B1. 框架检测 + +自动检测项目使用的测试框架： +- JavaScript/TypeScript：检查 package.json 中的 jest、vitest、mocha 等 +- Python：检查 pytest、unittest 等 +- 如果没有测试框架，询问用户是否需要安装 + +#### B2. 逐模块生成测试 + +按步骤计划中的模块划分： +- 为每个模块生成单元测试 +- 测试覆盖：正常路径、边界情况、错误路径 +- 生成测试代码后展示给用户确认 + +#### B3. 运行测试 + +- 执行生成的测试 +- 展示测试结果 +- 失败的测试进入修复循环：修复 → 重新运行 → 直到通过 + +#### B4. 测试结果记录 + +```markdown +## 模块测试详情 + +### 测试框架：Vitest + +| 模块 | 测试文件 | 用例数 | 通过 | 失败 | +|------|---------|--------|------|------| +| 模块A | xxx.test.ts | 5 | 5 | 0 | +``` + +### 阶段 C：全流程测试 + +#### C1. 设计测试场景 + +基于需求文档中的用户故事设计端到端测试场景： +- 每个用户故事对应至少一个测试场景 +- 场景应覆盖完整的用户操作流程 + +#### C2. 执行全流程测试 + +- 按场景逐步验证 +- 检查模块间的协作是否正常 +- 验证完整的数据流转 +- 检查集成点（API 调用、数据库操作等） + +#### C3. 记录结果 + +```markdown +## 全流程测试详情 + +### 场景 1：用户注册流程 +- 步骤 1：打开注册页 ✅ +- 步骤 2：填写表单 ✅ +- 步骤 3：提交注册 ✅ +- 步骤 4：验证成功 ✅ +``` + +### 生成测试报告 + +汇总所有阶段的测试结果： + +```markdown +# 测试报告：<项目名称> + +> 创建日期：YYYY-MM-DD +> 对应计划：docs/plans/YYYY-MM-DD-xxx.md +> 状态：已完成 + +## 审核摘要 + +| 阶段 | 状态 | 发现问题 | 已修复 | +|------|------|---------|--------| +| 代码审核 | 完成 | N | N | +| 模块测试 | 完成 | N | N | +| 全流程测试 | 完成 | N | N | +``` + +保存到 `docs/test-reports/YYYY-MM-DD-<项目名>.md`，提示下一步可调用 `/dev-deliver` 生成交付文档。 + +## 关键行为 + +- 代码审核以设计文档为基准，检查实现是否符合设计 +- 测试失败不跳过，必须修复后重新运行 +- 全流程测试按用户故事场景组织，确保端到端可运行 +- 兼容已有的 `automated-testing` 技能（框架检测和模板可复用） diff --git a/dev-workflow/SKILL.md b/dev-workflow/SKILL.md new file mode 100644 index 0000000..d048e6c --- /dev/null +++ b/dev-workflow/SKILL.md @@ -0,0 +1,138 @@ +--- +name: dev-workflow +description: 自动化开发工作流主控，串联需求→设计→计划→开发→测试→交付全流程 +--- + +# 自动化开发工作流 + +> 开发流程总控：管理全流程状态，引导用户按阶段推进，记录进度上下文。 + +## 调用方式 + +`/dev-workflow`，也可说"开始工作流"或"查看进度"。 + +支持指定阶段：`/dev-workflow 需求` 或 `/dev-workflow test` + +## 状态文件 + +`docs/workflow-status.md` + +## 执行流程 + +### 启动时 + +首先读取 `docs/workflow-status.md`（如存在），确定当前阶段和进度。如果不存在，创建新的状态文件。 + +### 阶段路由 + +根据用户输入或当前状态，引导至对应阶段： + +| 阶段 | Skill 指令 | 说明 | +|------|-----------|------| +| 需求分析 | `/dev-requirement` | 收集并确认需求 | +| 需求审核 | `/dev-review` | 评估相关性、复杂度，决定推进/拒绝/上报 | +| 技术设计 | `/dev-design` | 技术选型与架构设计 | +| TDD 测试先行 | `/dev-tdd` | 基于设计生成测试骨架（先写测试） | +| 步骤分解 | `/dev-plan` | 将开发工作拆解为可执行步骤 | +| 开发执行 | `/dev-develop` | 按步骤执行开发，让测试变绿 | +| 测试验证 | `/dev-test` | 代码审核、模块测试、全流程测试 | +| 交付发布 | `/dev-deliver` | 发布操作 + 生成交付文档 + 收集反馈 | + +### 状态跟踪 + +状态文件格式： + +```markdown +# 工作流状态 + +> 项目：[项目名] +> 创建日期：YYYY-MM-DD +> 最后更新：YYYY-MM-DD HH:MM + +## 阶段进度 + +| 阶段 | 状态 | 完成时间 | 产出文件 | +|------|------|---------|---------| +| 需求分析 | ⏳ 未开始 / ✅ 已完成 | - | docs/requirements/xxx.md | +| 需求审核 | ⏳ 未开始 / ✅ 已通过 / ❌ 已拒绝 / ⏸️ 待决策 | - | docs/reviews/xxx.md | +| 技术设计 | ⏳ 未开始 / ✅ 已完成 | - | docs/design/xxx.md | +| TDD 测试先行 | ⏳ 未开始 / ✅ 已完成 | - | docs/test-cases/xxx.md | +| 步骤分解 | ⏳ 未开始 / ✅ 已完成 | - | docs/plans/xxx.md | +| 开发执行 | ⏳ 未开始 / 🔄 进行中 / ✅ 已完成 | - | docs/dev-logs/xxx.md | +| 测试验证 | ⏳ 未开始 / ✅ 已完成 | - | docs/test-reports/xxx.md | +| 交付发布 | ⏳ 未开始 / ✅ 已完成 | - | docs/deliverables/xxx.md | + +## 当前阶段 + +[当前所处阶段及简要说明] + +## 建议下一步 + +- [ ] [具体的下一步操作建议] +``` + +### 阶段完成回调 + +每个阶段 skill 执行完成后，自动更新状态文件： +- 标记当前阶段为"已完成" +- 记录产出文件路径 +- 推荐下一步 skill + +### 断点续做 + +重新调用 `/dev-workflow` 时： +- 读取状态文件，定位到上次完成的阶段 +- 询问用户是继续下一阶段，还是回顾/修改已完成的阶段 +- 支持用户指定任意阶段重新执行 + +### 权限等级检测（启动时） + +工作流启动时检测当前自动批准权限范围，给出等级建议： + +**四个预设等级（配置模板位于 `.claude/permissions/`）：** + +| 等级 | 名称 | 自动批准范围 | 适用场景 | +|------|------|-------------|---------| +| level-1 | 严格模式 | 无，所有操作需确认 | 生产环境、敏感项目 | +| level-2 | 标准模式 | 只读操作（Read/Glob/Grep/ls/git status） | 日常查看、低风险 | +| level-3 | 开发模式 | 开发常用命令 + 只读 + 编辑 | **本工作流推荐** | +| level-4 | 完全自动 | 所有操作 | 仅隔离环境（Docker/worktree） | + +**检测逻辑：** +- 检查项目级 `.claude/settings.json` 是否存在 +- 根据 `permissions.allow` 的数量和范围判断当前等级 +- 如未配置或等级低于 level-2，提示用户调整 + +**切换方式：** + +```bash +# 方式一：项目级配置（仅影响本项目，推荐） +cp .claude/permissions/level-3-dev.json .claude/settings.json + +# 方式二：用户级配置（影响所有项目） +# 手动编辑 ~/.claude/settings.json，在 permissions.allow 中添加允许项 +``` + +**各阶段对权限的需求：** + +| 阶段 | 最小推荐等级 | 原因 | +|------|-------------|------| +| 需求分析 | level-2 | 主要是读取和提问 | +| 需求审核 | level-2 | 读取需求文档，生成审核报告 | +| 技术设计 | level-2 | 读取代码、生成设计文档 | +| TDD 测试先行 | level-3 | 需要创建测试文件、运行测试框架 | +| 步骤分解 | level-2 | 主要是读取和生成计划文档 | +| 开发执行 | **level-3** | 需要大量 Edit/Write/Bash（build/test/git） | +| 测试验证 | **level-3** | 需要运行测试、生成报告 | +| 交付发布 | level-3 | 需要 git tag/push、生成交付文档 | + +> **建议**：使用本工作流时至少配置为 level-3，否则每步操作都需要确认，流程推进效率极低。 + +## 关键行为 + +- 始终先读取状态，不重复创建已存在的文档 +- 阶段之间通过 `docs/` 目录传递上下文 +- 允许用户跳过阶段（用户明确选择时），但记录跳过的原因 +- 每个阶段结束后更新状态文件，确保进度不丢失 +- 不强制用户按顺序执行，但默认推荐线性流程 +- 权限不足时提示用户调整，不强行执行需要确认的操作