plan-and-build

用途：把一个小功能简报（Markdown 文件或内联描述）从“读懂”推进到“已实现、门禁通过、准备提交”。\n\n主要能力与流程：链式阶段，每阶段输出为下一阶段输入：简报→探索→计划→评审后计划→批准计划→测试代码→门禁通过→提交。特点一是松耦合：票据即 Markdown 简报或内联描述，无需议题跟踪器；门禁沿用仓库自身检查，不调用 CI 或云。二是每次只做一阶段：每阶段后总结并停止，等用户说继续再进入下一阶段，不合并阶段。\n\n使用方式：参数 $ARGUMENTS 为 .md 简报文件路径则读取；否则作为内联描述使用；为空则询问功能；简报过于单薄（无可见行为、无验收标准）则指出并追问。先重述目标并说明来源，暂停确认。阶段 1 探索：先读 AGENTS.md、CLAUDE.md 或 docs/ 上下文包，否则从代码推断约定；按仓库自身接缝并行派出探索子代理，返回存在的文件、涉及符号与边界情况，合成一张简图。阶段 2 起草计划：小步骤，标注确切文件与验证方式，用仓库自己的命令，第一步是实现失败测试。阶段 3 对抗性评审：并行三个通用子代理，分别从约定、正确性、范围视角批评，折叠成修订计划并说明取舍。阶段 4 人工检查点：调用 EnterPlanMode 再 ExitPlanMode 提交批准，批准前不写代码。阶段 5 实现：拆 3–8 步，按文件集划分可否并行；文件互不相交可并行子代理，同一文件需串行，先写失败测试再最小实现，逐步运行定向检查。阶段 6 门禁：运行仓库自身门禁命令，再跑 /code-review（中等力度，仅审查），不得委派子代理，红色绝不放过。阶段 7 提交：仅暂存改动文件，不 git add -A，提交信息引用简报，显示 diff stat。阶段 8 收尾：总结构建内容、测试、门禁结果与提交；说明到生产环境的桥接。\n\n限制：不主动 push 或开 PR，除非用户要求；不要把密钥放入 shell 或提交；门禁命令若不在预授权列表需手动批准，不得跳过或伪造。资料未提供具体安装命令、价格与平台信息。