用途：为编写代码提供一套从计划到交付的开发纪律，要求每一行代码符合当前最佳实践，而非仅“能运行”。
主要能力：按变更风险选择路径。新行为或已知原因缺陷走“失败清单→红→绿→重构”，先看到失败测试变红；纯重构走“基线绿→重构→绿”，不制造假的红；询问“现在该怎么写”时先核实当前来源再回答；原因不明的异常不属本技能，应先用 dig 定位原因。
使用方式：写代码前先做计划，按利害决定粒度，琐碎改动一句话即可，设计级改动写入 .issues/；安装 shaping 时由它充当计划器。计划包含验证：版本敏感内容（API、CLI、配置、惯用法）须对照权威来源，不可凭记忆书写。来源优先级为项目自身、官方文档（与已安装版本匹配）、开放网络；冲突时以经实战存活者优先。红阶段要有失败测试并贴出红色输出，测试走公共接口，不测内部实现；绿阶段写最小实现；重构阶段保持行为不变、测试不动。重构后做对抗式评审，用三个视角检查删除、抽象与调用方，并按严重度排序输出。纠错时先分类是理解错误、知识错误还是重复失败，再决定重读需求、核实来源还是转入 dig。
适用场景：功能开发、已知原因缺陷修复、纯重构、版本敏感写法咨询与代码评审。
限制：低风险且可恢复的改动可豁免，但须明确说明；配置改动可跳过 TDD 但不能跳过验证；spike 必须以带测试转正或被标注丢弃并删除收尾。资料未提供具体安装步骤、平台、收费或效果数据。