菜单
增量开发工作流，用于让代码演进保持小、可理解、模块化、可验证。用户要求下一步计划、小步计划、逐步实现、慢点实现、按计划继续、重构、重写、新项目搭建、架构梳理，或表达项目复杂度失控、想从头重写、希望重新获得掌控感时使用。也触发于中文短语：小步计划、按计划实现、继续实现、慢点实现、复杂度失控、想从头重写、重新获得掌控感；英文短语：next step, step-by-step, small steps, incremental implementation, keep it simple.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | incremental-dev |
| description | 增量开发工作流，用于让代码演进保持小、可理解、模块化、可验证。用户要求下一步计划、小步计划、逐步实现、慢点实现、按计划继续、重构、重写、新项目搭建、架构梳理，或表达项目复杂度失控、想从头重写、希望重新获得掌控感时使用。也触发于中文短语：小步计划、按计划实现、继续实现、慢点实现、复杂度失控、想从头重写、重新获得掌控感；英文短语：next step, step-by-step, small steps, incremental implementation, keep it simple. |
目标：让项目始终小到用户能够理解、判断和掌控。
同时遵循 karpathy-guidelines：先想清楚再写代码，外科手术式修改，避免推测性抽象，并为每一步定义客观验收方式。
核心规则：
一次只构建一个可理解的小切片。每完成一个切片，用户都应该知道：改了什么、为什么存在、如何验证、下一小步是什么。
当用户要求计划、下一步、架构思考、复杂度评估，或说“先思考/分析”时使用。
除非用户明确要求实现，否则不要改代码。
回复包含：
如果用户要求大计划，可以给简短阶段路线图，但最后必须落到一个下一小步。
当用户说“按计划实现”“继续按计划实现”“开始实现”“实施”等表达时使用。
只实现上一轮确定的下一小步。如果上下文里没有清晰小步，先读取相关文件，选择最小一致步骤，简短说明后再实现。
如果用户同时提出小的命名、目录或测试位置要求，只有在它和当前微步强相关且仍符合微步预算时才一起处理；否则先回答设计问题，把实现拆到后续步骤。
实现后：
当测试失败、用户贴出报错，或当前验收没有通过时使用。
只修复当前失败。不要扩展功能、重构邻近代码或推进路线图。
当用户说项目太复杂、失控、难以继续，或想从头重写时使用。
暂停功能开发，先重建项目地图：
优先删除、延后或命名边界，而不是增加抽象。
当用户问计划是否完成、接下来做什么，或要求阶段回顾时使用。
不要写代码。先总结：
一个合格的实现步骤通常满足大部分条件：
如果超过预算，先拆小。如果用户说“还是太大”，承认并继续拆，直到每步只引入一个容易解释的想法。
当用户要求较大的计划时：
这样保留方向感，但不让下一轮实现膨胀。
规划回复：
当前状态：...
下一阶段目标：...
下一小步：...
实施计划：
1. ...
2. ...
3. ...
验收标准：...
实现后的最终回复：
已完成：...
验证：...
下一小步可以是：...
保持短。这个技能是为了降低认知负担，不是为了产出漂亮但庞大的计划。
涉及行为变化时，默认先写或先调整一个 focused test，让它表达当前微步的验收标准，再实现代码让测试通过。
可以不先写测试的情况：
即使不先写测试，也必须在写代码前说清楚本步验收标准，并在完成后验证。
避免：
优先：