用途：把不确定的软件需求转化为已批准的规格说明、受控实施和可验证的验收证据，适用于新产品、中大型功能、跨模块改动，或需要 PRD、技术设计、多智能体执行与主智能体裁决的任务。不适合单文件小改动、微小缺陷修复、代码解释、仅审查或诊断、纯研究，以及规格已完整的简单任务。
主要能力：维护五份权威文档——PRD.md（范围、用户行为、业务规则、假设与产品决策）、TECH_DESIGN.md（架构、契约、数据、运维、安全与技术决策）、ACCEPTANCE.md（可观察的通过/失败标准与所需证据）、AGENT_PLAN.md（依赖、文件归属、验证与任务契约）、LOOP.md（可恢复的执行状态与追加式循环历史）。需求梳理阶段采用依赖树与前沿方法，每轮只提出一至三个可答问题，给出选项、影响与推荐理由，并立即更新文档。
使用方式：先检查 AGENTS.md、项目说明、既有规格与仓库约定，再起草 PRD.md，随后逐轮确认产品决策。产品边界清晰后编写并梳理 TECH_DESIGN.md，再冻结 ACCEPTANCE.md 并明确请求用户批准；未获明确批准前不得编写生产代码。批准后创建 AGENT_PLAN.md，按可独立验证的纵向切片拆分任务并冻结共享接口。并行委派前需确认写入不重叠。实施阶段的每个循环记录目标、FR/AC 编号、分配、依赖、证据、主智能体判断与下一步；判定结论仅限 ACCEPTED、CHANGES_REQUESTED、BLOCKED、ACCEPTED_WITH_CAVEATS。同一 AC 连续三个循环失败即停止自动返工并请用户决策。
限制：不能替代环境相关的测试，不授予无关改动或外部操作的授权。文档语言应与用户语言或仓库既有文档一致，FR-001、AC-001 等标识须保持稳定。不确定项须标注 TBD、ASSUMPTION 或 BLOCKED。子智能体报告仅为证据而非验收结论，主智能体负责集成与最终判断。若实施暴露的是需求变更而非代码缺陷，应停止相关工作、修订规格并重新取得批准。