每组包含 Leader、Executor、Reviewer 三个角色,主工作流仅对接各组 Leader
逐阶段推进,层层门禁把关
定义功能边界与验收标准
制定技术方案与接口规约
编码实现并交付产物
质量验证与交付完成
每个阶段均经历「组内修订闭环 → 组内评审通过 → 跨组评审」后进入下一阶段
产物:docs/{功能名}-需求文档.md
跨组评审:arch-leader(检查技术可行性)、dev-leader(检查实现歧义)、test-leader(检查可测试性)— 三方仅提供参考意见
产物:docs/{功能名}-详细设计.md
跨组评审:product-leader(检查需求偏离)、dev-leader(检查落地性)、test-leader(检查可测试性)
产物:源代码 + docs/{功能名}-实现摘要.md
实现摘要跨组评审:product-leader(检查功能点映射)、arch-leader(检查架构风险)、test-leader(检查偏离对测试影响)
特殊规则:测试回流至开发组时,dev-leader 须先对照设计文档检查实现与设计是否一致;若一致则问题在设计层面,应继续回流至架构组
测试阶段分三个子环节顺序推进,每个子环节有独立的组内评审和跨组评审。
产物:docs/{功能名}-测试用例.md、docs/{功能名}-测试报告.md、docs/{功能名}-使用手册.md
评审重点:product 检查需求覆盖度 100% | arch 检查架构风险点覆盖 | dev 检查代码路径覆盖与前端交互分层
每阶段组内评审通过后,由主工作流并行收集跨组评审结论统一判断
下游发现上游问题时,统一通过主工作流回流处理
各阶段设定组内、组外轮次上限,防止无限循环
| 阶段 | 组内轮次上限 | 组外轮次上限 | 最多调起 | 否决权持有者 |
|---|---|---|---|---|
| 需求阶段 | 6 轮 | 5 轮 | 6 次 | — (无否决权) |
| 设计阶段 | 6 轮 | 5 轮 | 6 次 | product-leader |
| 开发阶段 | 6 轮 | 20 轮 | 21 次 | product + arch |
| 测试阶段 | 每子环节 6 轮 | 40 轮 | 41 次 | product + arch + dev |
每个阶段形成可复用、已落盘的明确产物文件
| 阶段 | 产物路径 | 内容 |
|---|---|---|
| 需求 | docs/{功能名}-需求文档.md | 功能边界与验收标准 |
| 设计 | docs/{功能名}-详细设计.md | 技术方案与接口规约 |
| 开发 | 源代码 + docs/{功能名}-实现摘要.md | 代码 + 功能点设计项映射 |
| 测试 | docs/{功能名}-测试用例.md docs/{功能名}-测试报告.md docs/{功能名}-使用手册.md |
测试用例 / 测试报告 / 使用手册 |
以下为三个 install.sh 脚本部署的各文件目标路径
--global 安装到用户目录,--project [PATH] 安装到指定项目目录。
| 目录类型 | Global 模式 | Project 模式 |
|---|---|---|
| Skills | ~/.opencode/skills/ | {项目}/.opencode/skills/ |
| Agents | ~/.config/opencode/agents/ | {项目}/.opencode/agents/ |
| Commands | ~/.config/opencode/commands/ | {项目}/.opencode/commands/ |
| Plugins | ~/.config/opencode/plugins/ | {项目}/.opencode/plugins/ |
| SDLC 工作流 (sdlc/install.sh) | ||
|---|---|---|
| Skill | sdlc-workflow/SKILL.md | 源: sdlc/skills/sdlc-workflow/SKILL.md |
| Agents 4 个 Leader |
product-leader.md arch-leader.md dev-leader.md test-leader.md |
→ Agents 目录 源: sdlc/agents/*.md |
| Command | sdlc.md | → Commands 目录 |
| Plugin | sdlc-tracker.ts | → Plugins 目录 (跨阶段轮次追踪) |