在动手写代码前先画架构草图（类型/签名/模块边界）…

适用于非平凡改动：先建立系统心智模型、用多个模型产出结构不同的设计候选并综合成一份草图，再照草图实现；实现持续摩擦时果断丢弃草图重设计。

适用场景

解决思路

1. 开始前先开一个 todolist，每个阶段一条：1 Ground、2 Sketch、3 Agree、4 Implement、5 Scrap。
2. Phase A 接地：对所有新代码会触及的系统建立真实心智模型，在相关子系统上运行 how 技能。
3. 仅仅说出文件名不算 grounding；必须产出 how 规定的 traced model。
4. 如果设计重新定义了所有权或分层，还要对现有形态运行 why 技能，让既有理由成为约束而不是猜测。
5. 只有在确实是 greenfield、没有周边系统需要集成时，才跳过 Phase A。
6. Phase B 画草图：用 arena 技能执行设计草案任务，并带上 Phase A 的 grounding 产物；把 references/runner-prompt.md 作为每个 runner 的 prompt。
7. 让每个候选产出一份设计包，形状遵循 references/rationale-template.md。
8. 使用你已配置的 architect runners（默认 claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast）。
9. Design it twice：综合之前至少要有两个结构上不同的候选，即使第一个看起来已经足够好；要整形状的替代方案，而不是同一形状内的点修复。
10. 综合前用 references/design-red-flags.md 筛查每个候选；拒绝或修订 shallow modules、information leakage、temporal decomposition、pass-through methods。
11. 在接口深度上比较可行候选：优先选择把更多复杂度藏在更小、更简单的公共接口之后的设计；丰富的接口可以通过集中能力而保持调用链短，而不是把能力散落到各层。
12. arena 返回一份综合后的设计包，综合决策写入 rationale 的 "Synthesis decision" 段。
13. Phase C 达成一致（可选）：默认直接按综合后的设计进入实现，不设人工检查点。
14. 仅当调用方明确要求时才开启检查点，例如 "/architect with checkpoint"、"stop and show me before implementing" 之类；此时展示综合设计并暂停等待签字确认。
15. 无论是否设检查点，综合结果都可以作为独立 commit 提交，即 foundational-thinking 技能里的 "scaffold first" 模式。
16. 填充实现期间有计划、有范围的破坏是可以接受的（outcome-oriented-execution 原则）。
17. 若想在实现前对设计施加对抗压力，可在综合后的草图上运行 interrogate 技能。
18. 如果人类对形状提出异议（在检查点中或事后），把它当作 Phase A 的证据：重新接地并重跑 Phase B，再写更多代码。
19. Phase D 按草图实现：把 not implemented 的函数体替换成代码，把伪代码替换成逻辑；综合后的草图就是契约。
20. 偏离草图是值得浮出的信号，而不是默默吸收的摩擦：如果某个函数需要一个草图没预料到的参数，就问清楚是草图错了、需求漏了，还是实现越界了。
21. Phase E 架构不对就丢弃：如果实现持续产生草图无法吸收的摩擦，就扔掉草图；不要把补丁硬焊到错误设计上（redesign-from-first-principles、fix-root-causes）。
22. 识别信号要看 pattern 而不是单次实例，tells 包括：在互不相关的代码里反复出现同一种绕行方案；多个互不相关的边界情况都需要专门分支；类型需要逃生舱（any、强制转换、实践中总被赋值的可选字段）才能编译；草图说状态不共享时却出现“我们需要加锁”的条件反射；调用方必须了解抽象的内部规则才能使用它；实现里出现两个或更多形状相同的独立 Phase D 偏离。
23. 用判断力：几个边界情况不足以给架构判死刑；有些问题本来就复杂；数据里的复杂度不等于设计上的复杂度。
24. 丢弃草图时按顺序执行：1) 对已经构建的东西重跑 how 技能；2) 按 redesign-from-first-principles 重新设计，把新约束当成 day-one 假设；3) 按 subtract-before-you-add 先做减法再做加法，新草图在长大之前应该比旧草图更小；4) 回到 Phase B 重跑 arena。
25. 输出：先写调用方的使用方式（usage），类型草图从它派生；小改动用一个文件放新类型和签名，较大的工作用模块图加类型定义。
26. rationale 与代码一并交付，形状遵循 references/rationale-template.md，其中包含 usage sketch 和 synthesis decision。

适用边界 · 注意事项

• 工作确实是全新（greenfield）、没有周边系统需要集成时，不必做 Phase A 的 grounding。
• 不要在只有一个候选、或候选之间只是同形状点修复时就进入综合。
• 默认不要加人工检查点并暂停等签字，除非调用方明确要求。