分阶段门禁交付工作流

要解决什么问题

让 AI 写代码时，常见失败模式是：需求还没对齐就开始改文件、方案未确认就铺开重构、评审与测试被压缩成一句「已自测」，最后提交里混进无关改动。这类问题在业务规则、多表/缓存一致性、集成与状态迁移场景里代价更高。

本技能把一次编码请求收成带门禁的分阶段交付：阶段未完成或用户未确认，不默认进入下一阶段；发现需求缺口或方案级缺陷时，有明确的回退规则（例如实现与计划不符回到 Phase 3，评审发现架构问题回到 Phase 2）。

工作方式概览

Phase 0 先读仓库本地规则（如 AGENTS.md、CLAUDE.md），本地约束优先于技能默认流程。

主路径共八步：

1. 需求复述：用编号列出理解、现状、期望、边界与影响面；标出歧义与待确认点，此时不提技术方案。涉及业务规则时鼓励场景矩阵式描述（生效态、历史回放、主表/记录表等）。
2. 技术方案：模块、文件、数据路径、缓存与回滚风险；仍不写逐步编码计划。
3. 实施计划：可执行步骤、预期改动文件、验证与文档更新项。
4. 最小范围实现：只做已确认计划内的改动；发现额外问题先分类（阻塞/相邻/后续）并询问是否扩 scope。
5. 评审与风险修复循环：按严重度列 findings，与用户确认哪些必须现在修；可分组为必须修复、需确认、可接受残留。
6. 安全测试：按可用环境跑验证阶梯（静态检查 → 构建 → 定向自动化 → 集成/脚本 → 非破坏性 E2E）；不碰生产、不做破坏性操作。
7. 文档更新：即使小改也要更新最小相关文档集。
8. 范围化提交：仅在需求/方案/计划/评审/测试/文档均闭环后提交，且只包含任务相关文件。

输出模式：Strict 用于中等及以上风险工作；Compact 仅在任务极小、低风险且用户明确同意时启用——不跳阶段，只压缩表述。

适用边界

• 用户明确要求例外时，才可跳过阶段；否则按顺序执行。
• 测试若暴露超出已确认需求的行为，应停下询问是否视为范围扩张。
• 长任务应在每个阶段边界向用户同步进度；配套清单见技能内 references/checklists.md（按需引用）。