setup-pstack について
Setup pstack は、現在の Claude Code または Codex ハーネス向けに、移植可能なモデルシートを1つ設定するスキルです。役割とモデルの割り当て、effort を検証してモデルをプローブし、変更が承認されるまでは既存設定を維持します。
主な機能
- 01Claude Code と Codex の設定
- 02役割とモデルファミリーの対応付け
- 03effort の選択と検証
- 04読み取り専用のモデルプローブ
- 05設定の保持と読み戻し
活用シーン
- 01モデルシートの初回設定
- 02指定した役割の割り当て変更
- 03設定書き込み前のモデル検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ericlitman/ open-pstack --skill setup-pstackインストール後、Claude Code で/setup-pstackを入力して読み込まれたか確認します。
詳細
pstack の設定
現在の親ハーネス用に、持ち運び可能なモデルシートを 1 つ設定します。プローブや書き込みを行う前に、provider-dispatch.md とモデルカタログを読みます。ディスパッチルール、記述子の文法、カタログのモデルマトリックス、保持される旧モデル、ルートテーブルが契約です。割り当てられた各マトリックスファミリーについて、要求された effort を 1 つ選びます。2 つ目の設定ファイル、実行時リゾルバー、またはより低性能なモデルへのフォールバックを追加しないでください。
ハーネスの config-home ルールを使って、<config-home>を一度だけ解決します。現在の状態の読み取り、書き込み、スナップショット、復元、読み戻しのすべてで使用します。
Claude Code は<config-home>/pstack-models.mdに書き込み、ステップ 8 のインポートルールを使って<config-home>/CLAUDE.mdから読み込みます。<config-home>がデフォルトのホームの場合は、従来の行を正確に次のように出力します。
@~/.claude/pstack-models.md
CLAUDE_CONFIG_DIRによってホームがリダイレクトされている場合に限り、インポート元ファイルのディレクトリからの相対パスとして、@./pstack-models.mdを正確に出力します。
Codex は<config-home>/pstack-models.mdに書き込みます。Codex には@インクルードがないため、シートとまったく同じバイト列を<config-home>/AGENTS.md内の 1 つの範囲指定ブロックに複製し、シートを編集可能な唯一の情報源として保持します。
<exact contents of the resolved model sheet>
手順
1. 親を特定する
このスキルを実行しているハーネスとツール環境を使います。Claude Code または Codex のいずれかです。環境マーカーはその最上位の判断を裏付けるために使用できますが、子プロセスを起動して、どこから実行されたかを検出させてはいけません。親を記録します。同じ記述子でも、ハーネスによってルートが異なるためです。
2. 現在の状態を読み込む
<config-home>/pstack-models.mdと既存の統合設定を調べます。Claude の単一のモデルシートインポートを解決するか、Codex の単一の範囲指定モデルブロックを読み取り、存在しない参照先を報告して、読み取り不能、不正形式、または曖昧な状態があれば停止します。設定のうち 1 つだけが残っている場合はそれを使用し、両方の設定が一致する場合は編集可能なシートを使用します。Codex では、シートが正本であり、ブロックはそのミラーです。シートがない場合はブロックから復元できます。残っている設定同士が異なる場合は、両方の情報源と異なる割り当てを提示し、自動的にマージすることなく、正規化またはプローブの前に明示的な情報源の選択を求めます。復元可能な設定がどちらの情報源にも含まれていない場合に限り、初回実行時のデフォルトを使用し、選択した状態に既存の正規化、ロール補完、検証ルールを適用します。マトリックス検証の前に、カタログのローリングエイリアスに対するバージョン付き旧モデルのみを正規化します。照合順序は、モデルマトリックスの完全一致する行、保持される旧モデル、ローリングエイリアスのリビジョンです。登録済みの完全なピンなど、モデル自体がマトリックスの行である場合は、移行対象になりません。それ以外の、プロバイダーが指定された Claude モデルは、モデル部分がローリングエイリアスのバージョン付き旧モデルのプレフィックスで始まり、残りのリビジョンに数字とハイフン以外が含まれない場合に移行できます。プロバイダー、effort、ロール、レーンの順序を維持したまま、メモリー上でその部分をエイリアスに置き換えます。ステップ 7 での確認用に、元の記述子と正規化後の記述子をそれぞれ記録します。この移行は有効な読み込み済み状態であり、別途オペレーターの選択を必要としません。
codex writer sandbox: full-accessまたはcodex writer sandbox: boundedの行はロールではなく設定です。Codex writer sandboxでは、親がこの設定をどのように扱うかを説明しています。ロールのオーバーレイ、廃止されたロールのルール、記述子の検証を行う前に、この設定行を分離し、ステップ 6 から 8 まで引き継ぎます。設定行が 2 つある場合、または別の値が指定されている場合は、状態に矛盾があります。
正規化された値は、現在のロールとファミリーの割り当てとして扱います。カタログのロールのデフォルトにある、初回実行時のロールマップ全体にこれらの行を重ね合わせます。記載されているロールの行が不足している場合は、次回の書き込みが正常に完了した際に、そのマップから補完します。同じロールの行が重複している状態は一貫性がないため、報告し、確認の前に解決します。how criticsのように、ロールのデフォルトにないロールの行は、廃止されたロールのものです。その行を削除し、確認時に一覧表示します。古いシートにある、プロバイダーが示されていないホスト固有のスラッグも、どのプロバイダーが所有するか分からないため無効です。どのマトリックスの行、保持対象の旧モデル、ローリングエイリアスにも一致しないバージョン付きClaudeモデルは、一貫性のない状態です。値の(provider, model)が保持対象の旧モデルである場合は、一貫性のない状態ではありません。再実行時には、同じエフォートで、該当するすべての値をファミリーの現行モデルに置き換えることを提案し、確認します。オペレーターが同意しない場合、そのファミリーのモデルは手順3から7まで保持対象の旧モデルのままとします。プローブし、レンダリングし、変更せずに書き込みます。シートがない場合は、モデルマトリックスのデフォルトのエフォート欄を記述子に含むロールのデフォルトから初期化します。
次に、これらのロールとファミリーの割り当てを維持するか、指定したロールを変更するかを尋ねます。デフォルトでは割り当てを維持します。変更はオペレーターが指定したロールだけに適用します。カスタマイズ済みのシートを初回実行時の割り当てにリセットする選択肢は決して提示しません。変更するロールには、モデルマトリックスにある任意のファミリー、inherit-parent、またはautoを指定できます。
読み込んだ状態に設定行がない場合は、外部ランナーが起動するCodexのライター用レーンをCodexのフルアクセスサンドボックスで実行するかどうかを、一度だけ尋ねます。フルアクセスでは、ライターがブラウザーを起動したり、.agents/などのドットディレクトリに書き込んだりできること、また、ワークツリー内にファイルシステムを制限する機能を含め、すべてのサンドボックス制限が解除されることを伝えます。デフォルトではフルアクセスを許可しません。はいの場合はcodex writer sandbox: full-access、いいえの場合はcodex writer sandbox: boundedを記録し、再実行時に再度尋ねないようにします。設定行が存在する場合は、オペレーターが変更を指定しない限りその設定を維持し、尋ねません。
3. ファミリーごとのエフォートを解析する
カタログのモデルマトリックスと、引き継がれた先行モデルを確認します。エイリアス以外のロール値はすべて <provider>:<model>@<effort> に一致する必要があります。(provider, model) に基づいて、対応する先行モデルをそのファミリーに照合し、該当する行または引き継がれた先行モデルの行の Selectable efforts セルにエフォートが含まれていることを確認してから、そのエフォートを収集します。Selectable efforts セルに ultra が記載されていない行では、ultra を拒否します。inherit-parent と auto の行には、ファミリーのエフォートがありません。
これらのロールを担うレーンはファイルを書き込みます。isolated-write を委譲先とするプレイブックを使用する feature, refactoring、bug-fix、perf-issue、hillclimb、最も難しいコード変更を担う hardest tasks、および独自のワークツリーまたは出力ディレクトリに書き込む arena runners、architect runners、swarm workers です。ルートテーブルの Access modes セルに isolated-write がないプロバイダーには、これらのロールを割り当てないでください。ロール名とプロバイダー名を示し、その理由を説明します。ランナーは起動前にそのプロバイダーの書き込みレーンを拒否するため、手順 5 の読み取り専用プローブは通過しても、ロールの実行時に失敗します。そのロールには別のファミリーまたはエイリアスを指定するよう求め、変更されるまでプローブも書き込みも行わないでください。それ以外のロールでは、読み取り専用のプロバイダーを使用できます。
一致しないプロバイダー/モデル、ドメイン外のエフォート、または重複したロールは、不整合な状態です。処理を停止し、競合する行をそのまま表示して、明示的なマトリックスファミリーまたはエイリアスへの置き換えを求めてください。1 つ以上のファミリーでエフォートが混在している場合は、競合するすべてのファミリーとロールの行を表示し、各ファミリーについて Selectable efforts セルにあるエフォートを 1 つに正規化するよう求めてください。優先順位のルールを独自に作らないでください。不整合が解消されるまで、プローブも書き込みも行わないでください。
異なるエフォートがファミリーごとに 1 つだけある場合、それが現在の値です。エイリアス以外の出現がないファミリーは未割り当てです。そのファミリーのエフォートを尋ねたり、CLI を確認したり、プローブしたりしないでください。手順 2 でのロール変更によって新たに割り当てられたファミリーは、そのマトリックスの Default エフォートを提案値として使用します。
4. ファミリーごとに希望するエフォートを 1 つ収集する
割り当て済みの各ファミリーについて、エフォートを 1 つ尋ねます。各モデル名、現在値または提案値、およびそのマトリックス行の Selectable efforts を示します。選択可能なエフォートが default のみのファミリーについては、エフォートを尋ねません。入力が空の場合は、その値を維持します。初回実行時は、質問する前に割り当て済みファミリーのマトリックス上のデフォルト値を示します。再実行時は、解析した値を示し、カスタマイズ済みのロールレーンをリセットする選択肢は提示しません。
5. 希望するペアをプローブする
外部 CLI の利用可否や認証を確認したり、モデルをプローブしたりする前に、この親のルートテーブルを使って選択されたファミリーを解決します。Codex 親の場合は、割り当て済みの外部ファミリーを示し、親の有効な権限指示でネットワークアクセスと、各プロバイダーの注意事項にある状態パスおよびホストの前提条件を確認します。これには、必要なワークスペース外への書き込みも含まれます。権限を確認するために、認証情報の内容を確認したり、拒否される書き込みを試みたりしないでください。親自身の環境にある CODEX_SANDBOX_NETWORK_DISABLED=1 は、外部 CLI のネットワークアクセスが無効であることを示す証拠です。子の環境をスクラブする前に確認してください。CODEX_SANDBOX はサンドボックスのバックエンドを示すものであり、権限ポリシー全体を示すものではありません。マーカーがないこと、設定ファイルでの指定、または workspace-write という名前だけでは、十分なアクセス権があることの証明にはなりません。ワークスペース外のすべてのパスを一律に禁止するのではなく、有効なセッション権限と必要なパスを確認してください。
必要なアクセスがブロックされている場合は、CLI を実行する前に、影響を受ける割り当て済みファミリーと制限について説明してください。権限情報が利用できない、または不完全な場合は unknown とし、どの必須アクセスを確認できないかを説明して、外部チェックやプローブの前に解決してください。アクセスがブロックされている場合、または unknown のままである場合は、次の 2 つの経路だけを提示してください。
- オペレーターが意図的に選んだ適切な権限で親プロセスを再起動します。書き込みは行わず、このセットアップを停止してください。Grok のネストされたサンドボックスに関する制限を含め、provider-dispatch の ホストと親プロセスの前提条件を参照してください。
- この親プロセスについて、ネイティブのみを明示的に選択してロールを割り当てます。影響を受ける各ロールと置き換え案を示し、オペレーターが指定した変更を受け取ってから、手順 2~4 に戻り、ネイティブプローブの前に変更後のマップとエフォートを検証します。Codex では、
codexプロバイダーのファミリーはネイティブです。inherit-parentとautoもネイティブのままです。レーンを自動で変更したり、エフォートを下げたり、割り当て解除されたファミリーに対して外部 CLI を起動したりしないでください。プロバイダーの多様性が低下する場合は、その旨を伝えてください。
選択したファミリーがすべてネイティブの場合、外部 CLI の権限確認やプローブは不要です。ただし、最終書き込みの確認は別途必要です。実効権限で選択した外部レーンの使用が許可されている場合は、既存のルートと要求されたエフォートを変更せずに続行してください。セットアップの一環として、サンドボックス設定を変更したり、権限を昇格したりしないでください。
割り当てられた各ファミリーについて、選択した provider:model@effort の組み合わせだけをプローブしてください。ロールマップ内のファミリーごとに 1 回ずつプローブを実行します。2 つのファミリーが同じプロバイダーを共有する場合も同様です。古いモデルを代替候補として列挙したり提示したりしないでください。プローブが失敗した場合は何も書き込まず、失敗した組み合わせとプロバイダーを報告して停止し、アクティブなシートと親プロセスの統合バイト列を変更せずに保ってください。初回実行が失敗した場合、どちらの成果物も作成されません。
Grok のプローブが、ホストが制限付きサンドボックスを強制できないために失敗した場合は、ホストと親プロセスの前提条件を参照し、アクティブな設定を変更しないでください。
ルートテーブルでファミリーのプロバイダーを確認してください。ネイティブルートでは、ネイティブの 1 ターンプローブを実行します。Claude Code ではファミリーの pstack-<family>-<effort> エージェントを使用し、Codex ではディスクリプターのモデルと reasoning_effort を指定して spawn_agent を使用します。外部ルートでは、小さな読み取り専用プローブプロンプトを指定して pstack-runner を 1 回呼び出します。runner の事前チェックで CLI、ログイン状態、モデルを確認し、そのレシートを結果とします。
一意のマーカーを返す、小さな読み取り専用プローブを使用してください。ログイン状態のコマンドだけでは認証情報が確認できるだけで、要求したモデルとエフォートのフラグが動作することは証明できません。ネイティブと外部の結果は分けて記録してください。親プロセス自身のプロバイダーに対して、外部ランチャーを決して呼び出さないでください。
レシートとネイティブのトランスクリプトで証明できるのは、要求したエフォートとルートです。プロバイダー内部で実際に適用された推論の深さは証明できません。暗黙のタイムアウト、より弱いモデルへのフォールバック、同一プロバイダーの外部フォールバック、2 つ目の変更可能な設定ソースはありません。
6. ロールのファミリーを維持してレンダリングする
新しいシートはメモリ上で構築します。まだ書き込まないでください。
- 初回実行:カタログのロールデフォルトを基にし、手順 2 のロール変更を適用します。
- 再実行:手順 2 の正規化済み完全ロールマップを基にし、手順 2 のロール変更を適用します。読み込んだ各行のレーン順と、各レーンのファミリー(またはエイリアス)を維持します。
読み込んだシートに設定行がある場合は、手順 2 の設定行をその位置に維持します。手順 2 で設定行を追加する場合は、最後のロール行の後に配置します。
すべてのマトリックスファミリーのディスクリプターを provider:model@<requested effort for that family> に書き換えます。その際、各ファミリーには手順 2 で選択したモデルを使用します。inherit-parent と auto は変更しないでください。エフォートのみを変更する再実行では、ロールのファミリーを変更できません。Grok のエフォートを変更すると、Grok のすべての出現箇所が更新されますが、Sol のロールが Grok に移ることはありません。限定されていないスラッグ、利用できないルート、モデルマトリックスおよび引き継いだ旧モデル以外のモデル、またはプロバイダーとモデルの不一致は拒否してください。
7. 確認してコミットする
ローリングエイリアスの移行があれば、元の記述子と正規化後の記述子を示し、ステップ 2 で削除した廃止ロールの行も示します。次に、ステップ 2 で読み取ったソースファイル、新しい保存先 <config-home>/pstack-models.md、この親のルートテーブル、レンダリングしたすべてのロールと記述子、設定行を示します。読み込んだ割り当てを新しい保存先に引き継ぎます。明示的なロールまたはエフォートの変更、および文書化された正規化のみ変更できます。書き込む前に確認を求めてください。
Why と Reflect には、親のライブ MCP サーフェスが必要です。これらの調査担当、レビュー担当、統合担当のロールは、inherit-parent または auto のままにしてください。制限付きの外部ランナーは、周囲の MCP を意図的に省略します。inherit-parent と auto は常に検証されますが、パネルのプロバイダーの多様性が低下する場合はその旨を伝えてください。パネルロールでは、各エントリにつき 1 つのレーンが実行されます。リストの長さがファンアウト数になります。arena cross-judge pool は、可能な場合に Arena が親およびベース候補とは異なるプロバイダーを選ぶためのリストです。競走で別の記述子が明示的に割り当てられていない限り、swarm workers はすべてのワーカーのデフォルトです。
すべての非エイリアスロール値は <provider>:<model>@<effort> と一致し、ステップ 5 に合格している必要があります。
オペレーターが確認した後、親の有効な書き込み権限を、実際の両方の保存先(シートと親の連携設定。CODEX_HOME が設定されている場合はそれを通じて解決します)および必要なディレクトリ作成について個別に確認します。両方の成果物をメモリ上でレンダリングし、最初の書き込みまたはディレクトリ作成の前にこの確認を行ってください。ネイティブプローブが成功しても、設定の書き込み権限が付与されるわけではありません。制限された親でも CODEX_HOME 配下への書き込みが許可される場合があります。ワークスペース外だからという理由だけで拒否せず、解決後の各保存先を評価してください。いずれかの保存先への書き込みが拒否された場合、または権限が不明なままの場合は、保存先ごとの説明を添えて中止します。既存の成果物はすべてバイト単位で変更せず、初回実行ではどちらの成果物も作成しないでください。対象を上書きして権限を試したり、許可された成果物だけを書き込んだり、自動的に昇格を要求したりしてはいけません。
両方の保存先で書き込みが許可された場合に限り、ステップ 8 のスナップショットと読み戻し手順を使って、ステップ 6 のメモリ上のレンダリングを書き込みます。ロールのデフォルトを結果として貼り付けてはいけません。デフォルトはステップ 2 の初期値としてのみ使います。選択したエフォートと明示的なロール変更は、書き込み前に必ず値に反映してください。
8. 組み込む
どちらかを書き込む前に、親統合の内容をメモリ上にレンダリングします。
Claude では、統合箇所は <config-home>/CLAUDE.md にある @ インポート行のうち、対象のベース名が pstack-models.md のものです。既存のディレクトリやパス表記は問いません。<config-home> がデフォルトのホームディレクトリの場合は、レガシー表記を維持して @~/.claude/pstack-models.md と正確にレンダリングします。CLAUDE_CONFIG_DIR によってホームディレクトリがリダイレクトされている場合に限り、@./pstack-models.md と正確にレンダリングします。この相対インポートはインポート元ファイルのディレクトリを基準に解決され、シートも同じ場所にあるため、インポート行に設定ディレクトリの文字列は含まれません。再実行時は、その1行だけをその場で置き換え、関係のないバイト列はすべて保持します。一致するインポート行が0件の場合は、1行追加します。2件以上ある場合は、どちらかを書き込む前に停止して状態の不整合を報告します。別のインポートを追加したり、どれを置き換えるか推測したりしてはいけません。
Codex では、統合箇所は <config-home>/AGENTS.md 内の1組の と の間にある、シートの正確なバイト列です。再実行時はその境界内のブロック全体を置き換えます。初回実行時は末尾にブロックを1つ挿入します。どちらかのマーカーが欠落している、重複している、または順序が逆になっている場合は、境界を推測せず、停止して状態の不整合を報告します。
すべての対象について、現在のバイト列をスナップショットします。要求されたすべてのペアが合格し、オペレーターが確認した後に限り、シートと親統合を書き込みます。両方の対象を読み戻し、メモリ上のレンダリング結果と比較します。書き込みまたは読み戻しのいずれかが失敗した場合は、すべてのスナップショットを復元して、失敗を報告します。変更のない再実行では、正規化後のシートと統合の内容がバイト単位で同一にならなければなりません。
親固有のプローブを再実行せずに、モデルシートをハーネス間でコピーしてはいけません。同じホスト上でも、ルートの利用可否は異なる場合があります。
9. 動作スモークテスト
セットアップ完了を宣言する前に、この親から小規模な読み取り専用の混合パネルを実行します。選択した記述子をすべて含め、出力先とレシートのパスはそれぞれ分け、独立したクロスジャッジを用意します。Claude ネイティブエージェントとすべての外部プロセスは、ハンドルを保持したままバックグラウンドで起動し、その後、終了まで待機します。ネイティブのトランスクリプト項目とすべての外部レシートを検証します。構造的な設定チェックや単体テストで代用してはいけません。
シートのパス、親ルートテーブル、要求した処理能力のプローブ結果、スモークテストの結果、外部処理の経過時間・トークン数・コストのレシートを報告します。このスキルを再実行すると、プローブを再実行して同じシートを更新します。プロバイダーが非表示の適用済み処理能力の可観測性を提供したと主張してはいけません。