用途：读取 /plan 生成的任务清单（docs/work/YYYY-MM-DD-<slug>/tasks.md）与设计文档（plan.md），按顺序把每个任务实现为已提交、有测试支撑的代码，属于工作流中 /plan 之后的默认阶段。
主要能力：以 /dev 触发；每个任务分三步——派发实现者子代理（携带完整任务文本、设计文档相关段落、近期 git log），实现者用 RED-GREEN-REFACTOR 编码并提交；随后依次进行规格合规评审与代码质量评审，两者均通过才算完成。实现中出现规格空白时走决策门：按 7 项清单打分（共 14 分），0-3 分自行决定并记录，4-7 分转规格评审，8 分以上或触发强制覆盖（安全维度 2 分、schema 迁移、改动已实现任务、变更公开 API）则为 BLOCKED。决策记录写入 decisions.md。全部任务完成后做最终整体代码评审。
使用方式：先确认当前分支非 main/master、worktree 存在、任务文件存在、decisions.md 已创建；可选执行 forge sync 与 bash scripts/conflict-detect.sh --issue <forge-id> 做跨开发者冲突检查，冲突时可经 forge comment <id> "Conflict override: ..." 记录后继续。之后按逐任务循环执行 /dev。
限制与硬性门禁：完成声明必须有本会话内新跑出的验证证据，禁用“应该能过”“看起来没问题”等措辞；任务进度需通过 forge comment <id> 记录，命令报错则停止；规格评审未通过前不得运行质量评审；/dev 之后只能调用 validate，不得直接从 dev 开 PR；退出前所有决策须为 RESOLVED 或 PENDING-DEVELOPER-INPUT。
适用场景：已有 /plan 任务清单、需要按任务粒度执行 TDD 并保留审计轨迹的功能开发。具体收费、平台等信息暂未提供。