用途：在实现之前做设计。先勾勒类型、函数签名、类形状和模块边界，用未实现体和伪代码代替真实代码，综合多个模型视角与不同设计路线，选定草图后再由父流程按草图填代码；若实现证明草图有误，就丢弃并重新设计。
流程分五个阶段。开始前先建一个待办清单，每个阶段一条。
A 阶段：扎根问题。对新代码触及的每个系统建立真实心智模型，对相关子系统运行 how 技能；仅命名文件不算扎根，要产出 how 要求的追踪模型。若设计重新定义归属或分层，还要对既有形态运行 why，使理由成为约束而非猜测。只有在完全绿地、没有可集成周边系统时才可跳过本阶段。
B 阶段：草图。以 design-sketch 任务和 A 阶段产物运行 arena 技能，把 references/runner-prompt.md 作为每个 runner 的提示。每个候选只返回只读设计提案（按 references/rationale-template.md 成形），可查看源码、返回文本草图，不写文件、不实现、不派生代理。设计候选使用 Arena 的 pstack-arena-runner-1、2、3 三个 profile，默认 Astra、GPT-6.1 Sol、Opus 5.5，均为 xhigh；遵循 Arena 的 runner 选择、候选数量覆盖与缺失 profile 默认值。评估使用其单个 pstack-judge，始终 Astra xhigh。要“设计两次”，合成前至少要有两个结构上不同的候选，即使是整体形态级替代，而非同一形态内的点修补。合成前用 references/design-red-flags.md 筛查每个候选，拒绝或修正浅模块、信息泄漏、按时间分解和透传方法。可行的候选按接口深度比较，优先选以更小更简单的公开表面隐藏更多复杂度的设计。Arena 返回一个合成设计包，合成决定填入 rationale 的“Synthesis decision”部分。
C 阶段：确认（可选）。实现已在范围内时，父流程直接用合成设计进入实现，不设人工检查点；只做设计时，返回设计并停止。调用方明确要求（如“/architect with checkpoint”“实现前停下来给我看”）才启用检查点，展示合成设计并等待批准。实现已在范围内时父流程可提交合成结果；实现前想对设计施加对抗压力，可对合成草图运行 interrogate。若人对形态提出反对，视为 A 阶段证据，重新扎根并重跑 B 阶段再写更多代码。
D 阶段：按草图实现。父流程直接实现：把未实现体替换为代码、把伪代码替换为逻辑。设计候选不参与实现，合成草图即契约。偏离草图是要暴露的信号，而非默默吸收的摩擦；若某函数需要草图未预料的参数，要问是草图错了、需求漏了，还是实现越界。
E 阶段：架构错误时丢弃。若实现持续产生草图无法吸收的摩擦，就丢弃草图，不要给错误设计打补丁。信号是模式而非个例：无关代码反复出现同形状 workaround；多个无关边界情况都需要特殊分支；类型需要逃生舱（any、强制转换、实际总会设置的可选字段）才能编译；草图说状态不共享却出现“需要加锁”的反射；调用方必须了解抽象内部规则才能使用；D 阶段出现两个及以上同形状的独立偏离。需自行判断：几个边界情况不足以否定架构，有些问题确实复杂，数据的复杂度不等于设计的复杂度。丢弃时：对已构建内容重跑 how；按 redesign-from-first-principles 把新约束当作第一天的假设重新设计；按 subtract-before-you-add 先减后加，新草图在增长前应比旧草图更小；回到 B 阶段重跑 arena。
输出：先写调用方用法，再由其推导类型草图。小改动返回文本形式的返回类型与签名草图，较大工作返回模块图加类型定义；只有父流程写结果文件。理由说明随设计一并给出，按 references/rationale-template.md 成形，包含用法草图与合成决定。
限制：候选仅返回文本、不落盘；收费、价格、可用平台、实际效果等资料暂未提供。