用途：dev-team 用于把一个工作单元（规格、工单、发现或变更请求）从书面规格推进到已提交、已评审的结果。它组建一个小型智能体团队并运行有界循环：Dev 实现，QA 验证（“什么都不信”），Reviewer 做代码评审并创建提交。任何失败都会把具体反馈发回 Dev，达到循环上限后升级。它是严格实现流程的可复用核心，implement-full-spec 会在每个子任务上调用它一次。
主要能力：以智能体团队方式运行 Dev → QA → Reviewer → 提交的序列；每个角色是独立智能体，共享该工作单元不断演进的上下文（规格、diff、前轮反馈）。支持团队原语（如 TeamCreate + SendMessage）或降级为协调式子代理调度。
必要用法：开始前需固定契约——工作区绝对路径与分支、逐字规格、每条修复项的 IN/OUT-of-scope 划分、规范检查命令（typecheck、lint、指定测试套件等）。循环结束于分支上的提交，不推送、不开 PR，推送由调用方负责。QA 提示必须包含“心理回滚”条款：若把修复回滚，哪个测试会失败？若没有，测试就是表演。
适用场景：需要严格实现变更——构建、独立验证、代码评审后再落地。不适用于一行改动、需要各自 PR 的父工单（用 implement-full-spec），或同步结对编程。
限制：每个工作单元最多 3 轮 Dev → QA → Reviewer 循环，超限则升级并报告当前 diff、失败测试输出、评审最后反馈。硬性规则包括：提交不得使用 --no-verify；不得用 git add -A / git add .，须按文件名暂存；默认不 amend；不得触碰操作者主检出；每个 Dev/QA/Reviewer 提示都须包含逐字规格。团队须限定于一个工作单元并在提交后拆除。规格含糊、需要仓库外基础设施时须停止并上报。
产出：分支上的一个提交（未暂存 → 已评审 → 已提交），SHA 返回给调用方；或达到循环上限时带 diff、失败输出和最后反馈的升级。推送、开 PR、更新工单由调用方负责。提示模板见 references/prompt-templates.md。