关于 architect
architect 是用于规划和实现软件变更的开发技能，采用分阶段设计流程。它先梳理现有系统，再借助 arena 比较不同方案，并将选定草图作为实现契约。
主要功能
- 01基于现有系统建立设计背景
- 02绘制类型与模块草图
- 03比较不同设计方案
- 04按选定草图实现代码
- 05反复遇阻时重新审视架构
适用场景
- 01规划跨越系统边界的功能
- 02在编写实现前定义接口
- 03重做需要反复变通的设计
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/architect确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/design-red-flags.mdrationale-template.mdrunner-prompt.md详细介绍
架构设计
使用 not implemented 函数体和伪代码勾勒类型、函数签名、类结构和模块边界。综合多个模型视角，然后根据选定的草图补全代码。
开始
开始前，先创建一个待办清单，每个阶段对应一项。
- Ground（梳理背景）
- Sketch（设计草图）
- Agree（达成共识）
- Implement（实现）
- Scrap（废弃）
阶段 A：梳理问题背景
围绕新代码涉及的每个系统，建立切实、完整的心智模型。在相关子系统上运行 how 技能。仅仅指出某个文件并不算梳理背景。按照 how 的要求，给出架构说明。如果设计会重新定义所有权或分层，还要对现有结构运行 why 技能，让其设计理由成为约束，而不是猜测。
只有当工作确实是全新开发，且没有周边系统需要集成时，才跳过阶段 A。
阶段 B：设计草图
使用设计草图任务和阶段 A 的背景梳理材料运行 arena 技能。将 references/runner-prompt.md 作为每个 runner 的提示词。
使用 pstack 设置文件中的 architect runners 行所列的 runner（Cursor 中为 ~/.cursor/rules/pstack-models.mdc，Claude Code 中为 ~/.claude/rules/pstack-models.md，其他 harness 中为 ~/.agents/pstack-models.md），替代 arena runners 行。如果文件或该行缺失，则使用 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast。别名和被拒绝的条目遵循 arena 技能阶段 A 中的 runner 规则。
设计两轮。综合之前，至少要求两个结构上不同的候选方案，即使第一个看起来已经够用。这是将 exhaust-the-design-space 原则技能落到实处。要比较完整结构的备选方案，而不是在同一结构内做局部修补。
综合之前，使用 references/design-red-flags.md 检查每个候选方案。假设下一位贡献者是一个 Agent：它只会查看自己打开的文件，照搬最接近的示例，并选择能编译的最短路径。优先选择这样的设计：从单个文件来看似乎正确的改动，对整个仓库而言也确实正确。
根据接口深度比较可行的候选方案。优先选择能以更小、更简单的公共接口隐藏更多复杂性的设计。丰富的接口可以通过集中能力而非将能力分散到各层，来缩短调用链。
Arena 会返回一个综合后的设计方案包。其综合决策将填入理由说明中的「综合决策」部分。
阶段 C：达成共识（可选）
默认情况下，直接使用综合后的设计进行实现，无需人工检查点。
仅当调用者明确要求时才启用检查点，例如「/architect with checkpoint」「实现前先停下来给我看」或类似表达。此时展示综合后的设计并暂停，等待确认。
无论是否使用检查点，综合结果都可以作为独立提交提交，这正是 foundational-thinking 原则技能中的「先搭脚手架」模式。根据 outcome-oriented-execution 原则技能，填充代码时允许出现有计划且范围明确的破坏性变更。若要在实现前对设计进行对抗性检验，可对综合后的草图运行 interrogate 技能。
如果人工审阅者对结构提出异议（无论是在检查点还是事后），都将其视为阶段 A 的证据。重新梳理背景并重跑阶段 B，然后再编写更多代码。
阶段 D：根据草图实现
将 not implemented 函数体替换为代码，将伪代码替换为逻辑。综合后的草图就是契约。偏离草图是需要明确指出的信号，而不是可以默默消化的摩擦。如果某个函数需要草图中未预料到的参数，就要判断是草图有误、遗漏了需求，还是实现超出了范围。
阶段 E：架构错误时推倒重来
如果实现过程中不断出现草图无法消化的阻力，就推倒草图重来。不要在错误的设计上不断打补丁，遵循从第一性原理重新设计和修复根本原因原则技能。
信号在于模式，而非个别情况。迹象包括：
- 在互不相关的代码中反复出现相同形式的变通方案。
- 多个互不相关的边缘情况都需要特殊分支。
- 类型必须借助逃生通道（
any、类型转换、实际上总是设置的可选字段）才能通过编译。 - 草图明明说状态并非共享，却下意识觉得“我们需要一把锁”。
- 调用方必须了解抽象的内部规则才能使用它。
- 实现中出现两个或更多形态相同的独立阶段 D 偏差。
酌情判断。少数边缘情况并不能说明架构有问题。有些问题确实很复杂。数据复杂，不等于设计复杂。
推倒重来时：
- 针对已构建的内容，重新运行how技能。
- 按照从第一性原理重新设计的原则，假设新约束从第一天起就已确定，然后重新设计。
- 遵循先删减，再添加原则技能，先删减，再添加。新草图在扩展之前应比旧草图更精简。
- 返回阶段 B，重新运行 arena。
产出
先写出调用方的用法，再据此推导类型草图。小改动只需一个包含新类型和签名的文件。较大的改动则需要模块映射和类型定义。随附的设计依据应按照 references/rationale-template.md 编写，其中包括用法草图和综合决策。