setup-pstack

设置 pstack

编写 ~/.config/pstack/pstack-models.md，该文件用于按角色设置 pstack 的模型。技能在委派任务时会读取此文件。

步骤

1. 检测可用模型

调用 orchestrator_capabilities，保留 canRunChildTask 为 true 的提供方。这些提供方的模型就是你在本次会话中可以传给 delegate_task 子 Agent 的模型。仅以此为准。如果返回结果中没有符合条件的模型，请说明这一点，并为每个角色提供 inherit-parent。条目格式为 <providerInstanceId>/<model>，如果模型列出了 effort 选项（Claude 使用 effort，Codex 使用 reasoningEffort），则还需加上 (<effort>)。绝不要填写未由它返回的条目。别名 inherit-parent 和 auto 始终有效，即使它们不是检测到的模型。

2. 加载当前状态

默认的角色到模型映射是步骤 3(b) 中的规则，适用于步骤 5 中列出的角色。如果 ~/.config/pstack/pstack-models.md 已存在，请读取并将其 # budget 行和角色值视为当前选择。否则从这些默认值开始。角色不在步骤 5 中的行（例如 how critics）属于已弃用角色。删除这些行。

3. 预算、映射并确认

(a) 询问预算。 在对话中直接询问。提供以下四个选项，并使用这些确切标签；如果文件中记录了当前预算，也要指出。

• unlimited - max reasoning
• large - xhigh reasoning
• medium - high reasoning
• small - medium reasoning

(b) 应用预算。 根据技能默认值建立工作表；重新运行时，保留你按模型、列表或别名（inherit-parent、auto）更改过的角色。默认情况下，代码角色（feature, refactoring、bug-fix、perf-issue、hillclimb）以及 how explorer、why investigators、swarm workers 和 reflect tooling 角色，使用检测到的速度最快且能力强的编码模型。judgment and prose、hardest tasks、how explainer、why synthesizer 以及 reflect judgment, divergent, synthesizer 使用检测到的能力最强的模型。每个评审组角色（arena runners、arena cross-judge pool、architect runners、interrogate reviewers）最多使用三个条目，每个不同的检测到的提供方各选一个能力最强的模型。unlimited、large、medium 和 small 分别将每个真实条目（包括评审组条目）的 effort 设为 max、xhigh、high 或 medium，等级顺序为 max > xhigh > high > medium > low。如果模型没有列出目标等级，则使用该模型所列出的、低于或等于目标等级的最高等级；如果没有，则标记该角色需要选择。绝不要选择等级序列之外的选项，例如 ultra、ultracode 或 ultrathink。没有 effort 选项的模型不添加 (<effort>)。inherit-parent 和 auto 不变。因此，在 large 预算下，如果模型列出了 low、medium、high 和 max，则使用 high。

(c) 展示角色并确认。 展示每个角色及其模型，将任何不在检测结果中的真实条目标记为需要选择。也列出步骤 2 删除的每一行。询问对方是接受当前设置还是更改特定角色，并将检测到的模型以及 inherit-parent 和 auto 作为选项（两者都表示该角色使用父对话线程的模型）。在对话中直接询问。对于评审组角色（arena runners、architect runners、interrogate reviewers），值是一个列表，每个条目都会启动一个子 Agent，因此列表长度决定数量，别名条目也计算在内。arena cross-judge pool 也是一个列表，但在可能的情况下，Arena 会从中选择一个模型家族与父模型不同的值。swarm workers 是每个 worker 的默认模型，除非竞赛或比较为每个分支指定了其他模型。

4. 验证

每个填写的实际条目都必须出现在 orchestrator_capabilities 结果中。其提供方的 canRunChildTask 为 true，模型列在该提供方下；如果该模型有努力程度选项，所选努力程度必须是其中之一。没有努力程度选项的模型不能带有 (<effort>)。inherit-parent 和 auto 始终有效。如果所选实际条目不可用，请停止并再次询问。

5. 写入文件

将 ~/.config/pstack/pstack-models.md（如果 ~/.config/pstack/ 不存在，则创建该目录）写为普通文件，包含头部注释、一行带所选标签及其目标努力程度的 # budget，以及每个角色各一行，并使用 poteto-mode 使用的相同标签。覆盖整个文件，确保重复运行具有幂等性。格式：

# pstack model configuration. One line per role. Delete a line to fall back to the skill default.
# `inherit-parent` or `auto` as a value: the role runs on the parent thread's model (omit delegate_task `target`). Alias entries in a panel list still count toward its fan-out.
# budget: large (xhigh)
feature, refactoring: <providerInstanceId>/<model> (<effort>)
bug-fix: <entry>
perf-issue: <entry>
hillclimb: <entry>
judgment and prose: <entry>
hardest tasks: <entry>
how explorer: <entry>
how explainer: <entry>
why investigators: <entry>
why synthesizer: <entry>
reflect tooling: <entry>
reflect judgment, divergent, synthesizer: <entry>
arena runners: <entry>, <entry>, <entry>
arena cross-judge pool: <entry>, <entry>, <entry>
swarm workers: <entry>
architect runners: <entry>, <entry>, <entry>
interrogate reviewers: <entry>, <entry>, <entry>

6. 确认

告知用户文件已写入，并说明技能下次委派任务时会应用该文件，因为技能会在那时读取它。重新运行此技能会更新该文件。

7. 提供验证技能（可选）

检查项目是否有办法驱动真实应用来进行验证（verify-* 技能或现有测试框架）。如果没有，只询问一次：“想要一个项目本地的验证技能，让 Agent 能像用户一样驱动应用并证明更改有效吗？我可以用 /create-verification-skill 生成一个。”如果用户同意，请从此技能所在目录读取 ../create-verification-skill/SKILL.md（优先使用加载此文件时由你的测试框架提供的目录；否则，Claude Code 使用 ~/.claude/skills/setup-pstack/，Codex 使用 ~/.agents/skills/setup-pstack/），并按其中说明操作。如果用户拒绝，则继续，不再劝说。

8. 提供形式化验证技能（可选）

检查项目是否已有形式化验证技能（位于 .agents/skills/ 或 .claude/skills/ 中、会对代码运行模型检查器、证明或其他验证器的项目技能）。如果没有，只询问一次：“想要一个形式化验证技能，让 Agent 能证明代码的某项关键属性在适用范围内的所有情况下都成立，而不只是测试覆盖到的情况吗？我可以用 /create-formal-verification-skill 生成一个。”如果用户同意，请从此技能所在目录读取 ../create-formal-verification-skill/SKILL.md，并按其中说明操作。如果用户拒绝，则继续，不再劝说。