pstack-architect 是一个面向 Pstack 接口或模块设计的技能，用于调用者优先的草图设计，并依据选定的设计形状进行实现。它适用于 Pstack 接口或模块设计、调用者优先草图以及针对选定形状的实现工作。
主要能力与流程 该技能以分阶段流程组织工作，开始前需先建立一个待办清单，每个阶段对应一个条目。
阶段 A：Ground the problem（建立问题基础） 为新代码触及的每个系统建立真实的心智模型。对相关子系统运行 /pstack-how。仅命名文件不算建立基础，需产出 /pstack-how 所规定的架构解释。如果设计重新定义了所有权或分层，还需对现有形状运行 /pstack-why，使既有理由成为约束而非猜测。仅当工作确实是全新领域、没有可集成的周边系统时，才可跳过阶段 A。完成条件：新代码触及的每个系统都已具备 /pstack-how 所规定的架构解释，或工作属于全新领域。
阶段 B：Sketch（草图） 使用设计草图任务和阶段 A 的基础产物运行 /pstack-arena。将 references/runner-prompt.md 作为每个 runner 的提示。按 /pstack-arena 阶段 A 的方式，通过 /pstack-swarm 选择 runner，在宿主提供不同模型时使用不同模型。要求至少两个结构不同的候选方案后再综合，即使第一个看起来已足够。这是 /pstack-principle-exhaust-the-design-space 的具体化。候选方案应是整体形状的替代方案，而非同一形状内的点状修复。在综合前，依据 references/design-red-flags.md 筛查每个候选方案。假设下一位贡献者是一个只看到其打开文件的智能体，会复制最近的示例，并采取能编译的最短路径。优先选择那种“从单个文件看是正确的改动，对整个仓库也是正确的”设计。在 /codebase-design 的术语下，按接口深度比较可行候选方案。优先选择以更小、更简单的公共表面隐藏更多复杂性的设计。丰富的接口可以通过集中能力而非分散到各层来保持调用链简短。Arena 返回一个综合后的设计包，其综合决策填入理由的“Synthesis decision”部分。完成条件：至少两个结构不同的候选方案经过筛查，且 /pstack-arena 返回一个综合后的设计包。
阶段 C：Agree（可选确认） 默认：直接使用综合后的设计进入实现，无人工检查点。当调用者明确要求时选择启用检查点，例如“/pstack-architect with checkpoint”“stop and show me before implementing”或类似表述。此时展示综合后的设计并暂停等待签字确认。无论哪种方式，综合结果都可作为独立提交发布，即 /pstack-principle-foundational-thinking 的“scaffold first”模式。填充期间计划内、有范围的破坏是可以的，依据 /pstack-principle-outcome-oriented-execution。若要在实现前对设计施加对抗性压力，可对综合后的草图运行 /pstack-interrogate。如果人类对形状提出反对（在检查点中或事后），将其视为阶段 A 的证据。在写更多代码前重新建立基础并重新运行阶段 B。一旦人类已对某个接口签字确认，之后对其做出的不兼容变更（来自阶段 D 的偏离或阶段 E 的废弃）需回到人类处签字确认，之后才能有更多代码建立在其上。完成条件：综合后的设计被接受——默认接受，或在请求检查点时由人类签字确认。
阶段 D：Implement against the sketch（按草图实现） 将 not implemented 主体替换为代码，将伪代码替换为逻辑。综合后的草图就是契约。偏离它是需要暴露的信号，而非默默吸收的摩擦。如果某个函数需要草图未预料的参数，要问是草图错了、需求遗漏了，还是实现越界了。当存在实际可行的测试路径时，使用 /tdd 在草图的公共接缝处编写行为测试。完成条件：范围内不再有 not implemented 主体或伪代码，且每个对草图的偏离都已暴露。
阶段 E：Scrap when the architecture is wrong（架构错误时废弃） 如果实现持续产生草图无法吸收的摩擦，就丢弃草图。不要给错误设计打补丁，依据 /pstack-principle-redesign-from-first-principles 和 /pstack-principle-fix-root-causes。信号是模式而非单个实例。征兆包括：同一形状的变通方案在无关代码中反复出现；多个无关边缘情况都需要特殊分支；类型需要逃生舱（any、强制转换、实践中总被设置的可选字段）才能编译；草图说状态不共享时却出现“我们需要锁”的反射；调用方必须了解抽象的内部规则才能使用它；实现中出现两个或更多同形状的独立阶段 D 偏离。需自行判断。少数边缘情况不足以否定一个架构。有些问题确实复杂。数据中的复杂性不等于设计中的复杂性。废弃时：对已构建的内容重新运行 /pstack-how；依据 /pstack-principle-redesign-from-first-principles，把新约束当作第一天的假设来重新设计；依据 /pstack-principle-subtract-before-you-add，先减后加，新草图在增长前应比旧草图更小；返回阶段 B 并重新运行 /pstack-arena。完成条件：实现不再显示摩擦模式，或废弃的草图已重新经过阶段 B。
输出 先写调用方的用法，再从中推导类型草图。小改动输出一个包含新类型和签名的文件。较大工作输出模块映射加类型定义。理由随附发布，按 references/rationale-template.md 成形，包含用法草图和综合决策。
使用方式 该技能通过 /pstack-architect 调用，并可与 /domain-modeling、/pstack-how、/pstack-why、/pstack-arena、/pstack-swarm、/pstack-interrogate、/tdd 等技能配合使用。调用 /domain-modeling 以解析并读取调用项目配置的产物。只读调查和评审会报告文档漂移而不做编辑；创建或实现则通过该所有者协调已接受的模型变更。
适用场景 适用于 Pstack 接口或模块设计、调用者优先草图，以及针对选定形状的实现。
限制 资料未提供关于收费、价格、平台支持范围或具体效果的信息。部分行为依赖其他 /pstack-* 技能与 references 目录下的文件（如 references/runner-prompt.md、references/design-red-flags.md、references/rationale-template.md），这些文件的具体内容暂未提供。