用途：在实现之前先做设计。勾画类型、函数签名、类形状与模块边界，用未实现函数体和伪代码表达，综合多个模型视角后，再按选定草图填充代码；若实现证明草图有误，则丢弃并重新设计。
主要阶段：A 接地——对代码触及的每个系统建立真实心智模型，对相关子系统运行 how 技能；若设计重定义归属或分层，还要对现有形态运行 why 技能，仅当确属全新领域、无可集成系统时才跳过。B 草图——用设计草图任务运行 arena 技能，每个 runner 发一个 delegate_task（mode: "async"），用 task_status 收取；每个候选产出符合 references/rationale-template.md 的设计包；要求至少两个结构上不同的整体候选后再综合；综合前按 references/design-red-flags.md 筛查；在接口深度上比较，优先把更多复杂度藏在更小更简单的公共表面之后。C 同意（可选）——默认直接进入实现；仅当调用方明确要求检查点时才暂停等待确认。D 按草图实现——以综合草图为契约替换空函数体；偏离草图应被显式提出。E 架构错误时废弃——反复出现同类变通、多个无关边界情况需特判、类型需逃生通道、调用方须了解抽象内部规则、两个以上同形状偏离，都是信号；废弃时重跑 how、按第一性原理重设计、先减后加，回到 B 再跑 arena。
输出：先写调用方用法，再据此推导类型草图；小改动给一个含新类型与签名的文件，较大工作给模块图加类型定义；同时产出 rationale，含用法草图与综合决定。运行器从 pstack-models.md 的 architect runners 行取，角色对照 orchestrator_capabilities 解析，不得硬编码模型；文件或角色缺失时用该角色内置默认值。
限制：官方文本未提供，上述均据公开说明整理；具体命令、安装方式、收费与平台支持暂未提供。