菜单
全栈开发工作流编排器，按 8 阶段顺序执行：需求分析 → 技术选型 → 技术评审 → 程序设计 → 任务拆分 → 单元测试 → 代码开发 → 自我验证。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dev-workflow |
| description | 全栈开发工作流编排器，按 8 阶段顺序执行：需求分析 → 技术选型 → 技术评审 → 程序设计 → 任务拆分 → 单元测试 → 代码开发 → 自我验证。 |
| argument-hint | ["iteration-id"] |
| disable-model-invocation | true |
| allowed-tools | Read, Write, Grep, Glob |
用户通过 /dev-workflow 启动。可选传入 iteration-id 恢复已有迭代。
history-manager skill 执行 init（确保 docs/history.json 存在）。$ARGUMENTS 且为有效 iteration id，恢复该迭代；否则调用 history-manager 执行 new-iter 创建新迭代。history-manager 执行 status 读取当前迭代的 state，从该阶段继续执行。| 顺序 | 阶段 | Skill | 执行方式 | 说明 |
|---|---|---|---|---|
| 1 | 需求分析 | requirements-analysis | inline | 与用户对话，梳理功能点 |
| 2 | 技术选型 | technology-selection | inline | 询问全栈/前端/后端，选定技术栈 |
| 3 | 技术评审 | technical-review | fork/Explore | 评审架构可行性、API 契约、风险项 |
| 4 | 程序设计 | program-design | inline | 设计模块分层、流程、工程目录 |
| 5 | 任务拆分 | task-breakdown | fork/Plan | 将设计拆为可管理的开发单元 |
| 6 | 单元测试 | unit-testing | fork | 按任务单元设计测试用例 |
| 7 | 代码开发 | code-development | inline | 按测试驱动实现代码 |
| 8 | 自我验证 | self-verification | fork/Explore | 运行测试、集成验证、质量自检 |
history-manager 的 get-phase 和 check-file 检查该阶段是否已完成。若已完成则跳过，直接进入下一阶段。history-manager 的 set-phase <phase> <phase_id> 更新 history。{阶段缩写}-001 格式（如 req-001、ts-001）。同一迭代内递增。docs/{current_iteration_id}/。根据单元测试用例、任务拆分与程序设计实现代码，并通过测试验证。全栈工作流第 7 阶段。
根据需求、技术选型与技术评审设计程序结构、流程与工程目录。全栈工作流第 4 阶段。
从产品原型或用户描述中梳理功能点与细节要求，产出结构化需求文档。全栈工作流第 1 阶段。
根据全栈/仅前端/仅后端选择技术栈并产出选型清单。全栈工作流第 2 阶段，需先询问用户开发范围。
代码开发完成后运行全量测试、检查集成、代码质量自检，产出验证报告。在代码开发之后使用，为全栈工作流最后一步。
评审需求与技术选型的架构可行性，定义 API 契约、数据模型、识别风险项。在技术选型之后、程序设计之前使用。