用途
Architect 用于在正式编写实现代码之前，先勾勒类型、函数签名、类形状和模块边界。其做法是用未实现的方法体和伪代码进行设计，综合多个模型视角产出方案，然后对照选定的草图填充代码。触发方式包括 /architect、'architect this'、'design…' 等。
主要能力
- 在编码前产出类型草图、函数签名与模块结构。
- 要求至少两个结构上不同的候选设计，即使第一个看起来已足够，也会先做多方案综合。
- 使用未实现的方法体和伪代码表达设计。
- 在填充实现时保持对照草图，偏离草图时视为信号而非静默吸收。
- 当实现持续产生草图无法吸收的摩擦时，建议废弃草图并重新设计。
使用方式
流程分为多个阶段：
- Phase A：Ground the problem（扎根问题）——对新代码触及的每个系统建立真实心智模型，对相关子系统运行 how 技能。命名一个文件并不等于扎根。仅当工作确属全新、无周边系统需要集成时，才可跳过此阶段。
- Phase B：Sketch（草图）——以 design-sketch 任务和 Phase A 的扎根产物运行 arena 技能。要求至少两个结构上不同的候选方案后再综合。对所有候选方案依据设计红旗清单进行筛查，在接口深度上比较可行方案，偏好用更小的公共面隐藏更多复杂度。
- Phase C：Agree（opt-in，可选确认）——默认直接进入实现，无人工检查点。仅在调用者明确要求时（如“/architect with checkpoint”“stop and show me before implementing”）才暂停等待确认。
- Phase D：Implement against the sketch（对照草图实现）——用代码替换未实现的方法体、用逻辑替换伪代码。综合后的草图即契约，偏离是应浮现的信号，而非应静默吸收的摩擦。
- Phase E：Scrap when the architecture is wrong（架构错误时废弃）——若实现持续产生草图无法吸收的摩擦，则丢弃草图，不把修复硬加在错误设计上。信号是模式而非单一实例，例如：同一形态的变通做法在无关代码中反复出现、多个无关边界情况都需要特殊分支、类型需要逃生舱（any、类型转换、实践中总会设置的可选字段）才能编译、草图说状态不共享却出现“需要加锁”的反射、调用方必须了解抽象内部规则才能使用、实现中出现两处或以上同形态的独立偏离。废弃时：对已构建内容重新运行 how 技能；按 redesign-from-first-principles 将新约束当作第一天假设重新设计；按 subtract-before-you-add 先减后加，新草图在生长前应比旧草图更小；返回 Phase B 重新运行 arena。
输出
调用方的用法先写出，再从用法推导类型草图。小改动输出一个包含新类型与签名的文件；较大工作输出模块图加类型定义。理由说明随附交付，按理由模板组织，包含用法草图和综合决策。
适用场景
适用于需要在编码前明确类型、签名和模块结构的开发工作，尤其是涉及既有系统集成、需要设计空间穷尽和多方案比较的场景。
限制
该技能大多数 pstack 技能仅限用户使用，技能工具无法加载它们。Phase A 仅在工作确属全新、无周边系统集成时才可跳过。具体运行器配置、模型配置及相关依赖未在资料中提供。