architect
Architect
Section titled “Architect”先设计，再实现。用 not implemented 函数体和伪代码，画出类型、函数签名、类的形态和模块边界。把几个模型的视角综合起来，再照着选定的草图填代码。如果实现证明草图错了，就扔掉草图，重新设计。
动手前先开一个 todolist，每个阶段一条。
- 摸清
- 草图
- 确认
- 实现
- 推倒
阶段 A：摸清问题
Section titled “阶段 A：摸清问题”新代码会碰到的每个系统，都要真正建立心智模型。对相关子系统运行 how skill。
说出一个文件名不算摸清。要产出 how 规定的、沿调用链追过的模型。如果设计要重新划定归属或分层，还要对现有形态运行 why skill，让当初的理由成为约束，而不是靠猜。
只有工作确实是从零开始、周围没有要对接的系统时，才跳过阶段 A。
阶段 B：画草图
Section titled “阶段 B：画草图”运行 arena skill，任务是画设计草图，并带上阶段 A 摸清问题时产出的材料。把 references/runner-prompt.md 作为每个 runner（各自独立出方案的模型）的提示词。每个候选按 references/rationale-template.md 的结构产出一份设计包。
runner 取 pstack-models.mdc rule 里的 architect runners 这一行，不用 arena runners 那一行。如果没有这条 rule 或没有这一行，就用 claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast。别名和被拒的条目，按 arena skill 阶段 A 里的 runner 规则处理。
设计两遍。综合之前至少要有两个结构上不同的候选，第一个看起来够用也一样。这就是 exhaust-the-design-space 原则 skill 落到实处。要的是整体形态不同的方案，不是在同一个形态里修修补补。
综合之前，拿 references/design-red-flags.md 把每个候选筛一遍。浅模块、信息泄漏、按时间顺序拆分、透传方法，要么改，要么拒。
在可行的候选之间比较接口深度。哪个设计用更小、更简单的公开接口藏住更多复杂度，就选哪个。接口能力丰富，可以把能力集中在一处，而不是分散到好几层，调用链反而更短。
arena 最后返回一份综合后的设计包。综合时做的决定，写进 rationale 的「综合决策」一节。
阶段 C：确认（可选）
Section titled “阶段 C：确认（可选）”默认：直接拿综合后的设计去实现，中间不停下来等人。
只有调用的人明确要求时，才加一个确认点，比如「/architect with checkpoint」「实现之前先停下来给我看」之类。这时把综合后的设计拿出来，停下等对方点头。
两种情况下，综合结果都可以单独作为一次提交，也就是 foundational-thinking 原则 skill 说的「先搭脚手架」。按 outcome-oriented-execution 原则 skill，填代码期间有计划、有范围的临时破坏没有关系。如果想在实现前对设计做一次对抗性施压，对综合后的草图运行 interrogate skill。
如果人对形态有异议（在确认点上或者事后提出），把它当作阶段 A 的证据。先重新摸清问题、重跑阶段 B，再接着写代码。
阶段 D：照着草图实现
Section titled “阶段 D：照着草图实现”把 not implemented 函数体换成代码，把伪代码换成逻辑。综合后的草图就是契约。
偏离草图是值得说出来的信号，不是该默默消化的阻力。如果某个函数需要草图没想到的参数，问一句：是草图错了，是需求漏了，还是实现做多了。
阶段 E：架构不对就推倒
Section titled “阶段 E：架构不对就推倒”如果实现一直在产生草图消化不了的阻力，就扔掉草图。按 redesign-from-first-principles 和 fix-root-causes 原则 skill，不要在错误的设计上继续打补丁。
要看的是规律，不是单个现象。征兆有：
- 同一种 workaround 在互不相关的代码里反复出现。
- 好几个互不相关的边界情况都要加特殊分支。
- 类型要靠逃生口（
any、强制转换、实际上总会被赋值的可选字段）才能编译通过。 - 草图说状态不共享，却冒出「这里得加锁」的念头。
- 调用方得知道抽象内部的规矩才能用它。
- 整个实现里有两处或更多互相独立、但形态相同的阶段 D 偏离。
要自己判断。几个边界情况不足以判一个架构的死刑。有些问题本来就复杂。数据复杂不等于设计复杂。
推倒的时候：
- 对已经写出来的东西重新运行 how skill。
- 按 redesign-from-first-principles，把新约束当成第一天就有的前提，重新设计。
- 按 subtract-before-you-add 原则 skill，先减再加。新草图在长大之前，应该先比旧草图小。
- 回到阶段 B，重跑 arena。
先写调用方怎么用，再从用法推出类型草图。小改动是一个文件，放新类型和签名。大一点的工作是模块图加类型定义。rationale 跟着一起交，按 references/rationale-template.md 的结构写，里面有用法草图和综合决策。