小范围低风险明确改动快速实现：在需求清晰且验证直接时安全落地…

适用于需求明确、改动面小、架构风险低、可快速验证的小型低风险变更。

适用场景

解决思路

1. 编码前先做 Scope Gate 资格检查：确认需求清晰，预期行为明确，没有重大产品/架构歧义。
2. 确认改动面小：通常不超过 5 个文件，且不进行广泛跨模块重构。
3. 确认架构风险低：不包含基础性重设计、重迁移改动或多阶段上线依赖。
4. 确认验证直接：能用针对性测试/检查快速验证，不需要长时间探索性调试。
5. 如果以上任一条件不满足，升级到 `write-plan`。
6. 出现硬停止升级条件时立即停止快速实现并转为规划：需求歧义需要设计决策。
7. 出现跨多个子系统的意外耦合时，停止并转规划。
8. 出现重大数据模型或 schema 变更时，停止并转规划。
9. 出现安全敏感或合规关键改动时，停止并转规划。
10. 出现需要基准测试/设计权衡的性能工作时，停止并转规划。
11. 重构超出原始小范围时，停止并转规划。
12. 多次失败且没有清晰根因时，停止并转规划。
13. 需要分阶段交付、特性开关或迁移策略时，停止并转规划。
14. 升级动作：立即停止所有编码活动。
15. 升级动作：输出精确消息："This change exceeds rapid-implementation safety limits. Recommend `write-plan` first to define phased execution and risk controls."
16. 升级动作：使用 input/question 询问用户是否要发起向 `write-plan` 技能的交接。
17. Step 1：理解用户请求并定义验收标准。
18. 只加载与请求相关的项目上下文：如果 `docs/SUMMARY.md` 存在，先读它。
19. 只加载与任务相关的详细文档。
20. 实现约定优先使用 `Code Standard` 文档。
21. 如果文档与代码或用户意图冲突，在广泛修改前使用可用的 input/question 询问。
22. 只检查最小必要的代码路径。
23. 确认任务仍通过 Scope Gate。
24. 如果仍有歧义，在编码前提出澄清问题。
25. Step 2：做满足需求的最小正确变更。
26. 复用现有模式和约定。
27. 避免与请求无关的机会主义重构。
28. 适用时保持变更幂等且可安全重跑。
29. Step 3：使用适当执行工具做与变更成比例的验证：运行与修改行为相关的针对性测试。
30. 对涉及区域运行相关 lint/type 检查。
31. 如适用，进行构建或运行时验证。
32. 如果验证意外失败：若明显局部，尝试聚焦修复。
33. 如果失败表明影响更广，建议升级到 `write-plan`。
34. Step 4：总结改了什么以及为什么。
35. 列出修改的文件。
36. 报告验证命令和结果。
37. 如果次要行为或领域规则发生变化，更新文档。
38. 执行边界：未经用户明确批准，不扩大范围。
39. 执行边界：不假设未指定行为；改为澄清。
40. 执行边界：风险增加时不要强行完成，尽早升级。
41. 执行边界：当复杂度或风险超过 quick-implement 限制时，升级到 `write-plan`。
42. 执行边界：当任务主要是调试问题时，使用 `fix`。
43. 最终回复前确认 Output Checklist：Scope Gate 已满足。
44. 确认没有引入隐藏的架构变更。
45. 确认已运行并报告验证。
46. 确认超过安全限制时已使用升级。

适用边界 · 注意事项

• 不适用于需求不清晰、需要设计决策、涉及多子系统耦合、重大数据模型/schema 变更、安全/合规关键、性能基准/权衡、分阶段交付/特性开关/迁移策略等；任一不满足 Scope Gate 或触发硬停止条件时应改用 `write-plan`。
• 不适用于主要目标是调试问题；应使用 `fix`。
• 不适用于改动可能扩大到跨模块重构，或反复失败且没有清晰根因的情况；应停止并转规划。