setup-pstack について
pstack のロール別モデル設定を対話形式で行い、`~/.config/pstack/pstack-models.md` に書き込むスキルです。利用可能なモデルの検出、予算に応じた初期値の設定、選択の確認と検証を行い、後続の委譲に備えます。
主な機能
- 01委譲タスクを実行できるモデルの検出
- 02ロールと予算に応じたモデル設定
- 03選択の確認と推論レベルの検証
- 04pstack 設定ファイルへの書き込み
- 05検証スキルの選択肢を提示
活用シーン
- 01pstack のロール別モデル設定
- 02利用可能なモデルの変更後に割り当てを調整
- 03予算に応じたモデルの推論レベル設定
MCP 対応
このスキルは `orchestrator_capabilities` を呼び出して子タスクを実行できるモデルを調べ、pstack の委譲用設定を作成します。MCP サーバーをクライアントに提供するとは記載されていません。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mariusflorescu/ pstack-t3 --skill setup-pstackインストール後、Claude Code で/setup-pstackを入力して読み込まれたか確認します。
詳細
pstack のセットアップ
pstack がロールごとに使用するモデルを設定するファイル ~/.config/pstack/pstack-models.md を作成します。スキルはタスクを委任するときにこのファイルを読み込みます。
手順
1. 利用可能なモデルを検出する
orchestrator_capabilities を呼び出し、canRunChildTask が true のプロバイダーを残します。このセッションで delegate_task のサブエージェントに渡せるのは、そのモデルだけです。情報源はこれだけです。利用可能なモデルが返されない場合は、その旨を伝え、すべてのロールに inherit-parent を指定するよう提案してください。エントリは <providerInstanceId>/<model> です。モデルに effort オプション(Claude の effort、Codex の reasoningEffort)がある場合は、さらに (<effort>) を付けます。返されたことのないエントリは絶対に記述しないでください。inherit-parent と auto のエイリアスは、検出されたモデルでなくても常に有効です。
2. 現在の状態を読み込む
デフォルトのロールとモデルのマッピングは、手順 5 に示すロールに対する手順 3(b) のルールです。~/.config/pstack/pstack-models.md がすでに存在する場合は、その # budget 行とロールの値を現在の選択として扱います。存在しない場合は、これらのデフォルトを使用します。手順 5 にないロール(how critics など)の行は、廃止されたロールのものです。削除してください。
3. 予算、割り当て、確認
(a) 予算を尋ねる。 スレッド内で簡潔に尋ねてください。次の 4 つの選択肢を、ラベルを正確に保って提示し、ファイルに現在の予算が記録されている場合はその予算を明示してください。
unlimited - max reasoninglarge - xhigh reasoningmedium - high reasoningsmall - 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)には、検出されたプロバイダーごとに最も高性能なモデルを、最大 3 つまで割り当てます。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)の値はリストで、エイリアスのエントリも含め、各エントリにつきサブエージェントが 1 つ実行されるため、リストの長さが実行数になります。arena cross-judge pool もリストですが、Arena は可能な場合、親とはモデルファミリーが異なる値を 1 つ選びます。swarm workers は、レースまたは比較によって実行単位ごとに別のモデルが割り当てられない限り、すべてのワーカーに適用されるデフォルトモデルです。
4. 検証する
実際のエントリーとして記述するものはすべて、orchestrator_capabilities の結果に含まれている必要があります。そのプロバイダーでは canRunChildTask が true であり、モデルはそのプロバイダーの配下に記載されていて、effort がある場合は、そのモデルの effort オプションのいずれかである必要があります。effort オプションのないモデルには (<effort>) を付けません。inherit-parent と auto は常に有効です。選択した実際のエントリーが利用できない場合は、停止してもう一度尋ねてください。
5. ファイルを書き込む
~/.config/pstack/pstack-models.md を(~/.config/pstack/ が存在しない場合は作成して)プレーンファイルとして書き込みます。ヘッダーコメント、選択したラベルとその target effort を記載した # budget 行、および各ロールにつき1行を含め、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-* スキル、または既存のハーネス)があるか確認してください。ない場合は、次のように一度だけ提案します:「ユーザーと同じようにエージェントがアプリを操作し、変更が機能することを確認できる、プロジェクト固有の検証スキルが必要ですか? /create-verification-skill で生成できます。」はいの場合、このスキルのディレクトリ(このファイルを読み込んだときにハーネスから指定されたもの。指定がない場合は、Claude Code では ~/.claude/skills/setup-pstack/、Codex では ~/.agents/skills/setup-pstack/)にある ../create-verification-skill/SKILL.md を読み、その指示に従ってください。いいえの場合は、それ以上勧めずに先へ進みます。
8. 形式検証スキルを提案する(任意)
プロジェクトにすでに形式検証スキル(.agents/skills/ または .claude/skills/ にある、モデルチェッカー、証明、またはその他の検証器をコードに対して実行するプロジェクトスキル)があるか確認してください。ない場合は、次のように一度だけ提案します:「テストで到達するケースだけでなく、対象範囲内のあらゆるケースでコードの重要な性質が成り立つことをエージェントが証明できる、形式検証スキルが必要ですか? /create-formal-verification-skill で生成できます。」はいの場合、このスキルのディレクトリにある ../create-formal-verification-skill/SKILL.md を読み、その指示に従ってください。いいえの場合は、それ以上勧めずに先へ進みます。