setup-pstack

pstack のセットアップ

PR テンプレートに限定したリクエストの場合は、ステップ 0e のみを実行してください。完全なセットアップでは、以下の該当するすべてのステップを実行します。

pstack のモデル設定を書き込みます。これは、役割ごとに pstack のモデルと推論の強度を設定するファイルです。エージェントは、このスキルのリゾルバーを使って役割ごとに設定を解決します。ワークスペースの .agents/pstack-models.md はユーザーの ~/.agents/pstack-models.md より優先され、どちらのファイルでもハーネス別のセクションは単独の行より優先されます。また、どちらのファイルにも記載されていない役割は、examples/pstack-models.md に同梱されたデフォルトにフォールバックします。したがって、これはオーバーライド用のレイヤーであり、必須要件ではありません。

インラインのデフォルトには短いモデルエイリアス（fable、opus、sonnet、haiku）が記述されています。これらは Codex では gpt-6 モデルに、Grok Build では grok-4.7 に変換されます。サブエージェントでハーネスが受け付けない値を指定すると、inherit-parent として扱われます。つまり、その役割ではセッションのモデルが実行され、複数モデルのパネルは同一モデルのパネルになります。エントリーには model@effort の形式で推論の強度を固定できます。また、## codex、## claude-code、## grok、## hermes の各セクションには、特定のハーネスにのみ適用される行を記述します。構文、階層、推論の強度に関するポリシーは、references/models-config.md で一元的に定義されており、scripts/check-models-config.py --resolve で適用されます。

ステップ

0a. ペルソナと任意のネイティブ登録を確認する

pstack-harness スキルの登録リファレンスを読みます。portable-paths.mdを使って、論理的なインストール済みスキルのルートを解決し、次を実行します。

python3 "${PSTACK_SKILLS_ROOT:?}/pstack-harness/scripts/subagents.py" check

失敗の兆候：終了コードが 0 以外です。ペルソナの準備完了を報告する前に、不足しているペイロードや同階層のスキルを修復してください。ペイロードの準備ができていれば、ネイティブ登録を行わなくても、汎用の委任先にペルソナ全体を渡せます。

この確認の対象はペイロードのみで、すべてのネイティブファイルは not-requested と報告されます。ペルソナまたは実行負荷エージェントがすでに登録されている場合は、poteto-agent、comment-sicko、または pstack-effort-<level> ファイルがある各 CLI とスコープについて、登録リファレンスのネイティブ check も実行します。対象は ~/.claude/agents、~/.codex/agents、またはプロジェクトの .claude/agents、.codex/agents です。いずれかの行が outdated-generated を報告した場合は、その CLI とスコープに対するリファレンスの install を提案します。同じグループの別の行が conflict を報告した場合は、グループ内のファイルは何も書き込まれないため、代わりに競合を報告してください。ペルソナと実行負荷エージェントは別々のグループなので、一方の競合がもう一方を妨げることはありません。スキルを更新しても、登録済みのペルソナや実行負荷エージェントは更新されません。

ユーザーが希望する場合は、Claude Code または Codex へのネイティブ登録を提案してください。セッションでスコープがすでに認可されている場合は、そのスコープを使用してください。そうでなければ、プロジェクトスコープかユーザースコープかを一度だけ尋ねてください。登録リファレンスに従い、Codex を独自の CODEX_HOME を持つラッパー経由で実行する場合は、ユーザースコープ単独、またはユーザースコープとの併用でプロジェクトスコープを推奨してください。選択した絶対パスのルートを使って、リファレンスの install コマンドを実行します。ペルソナを登録するために競合を上書きしたり、モデル設定を変更したりしてはいけません。Hermes では、委任コンテキストを通じて完全なブリーフィングを渡し、ネイティブのエージェントファイルは作成しないでください。Grok Build には独自の登録機能がありません。Claude Code のラッパーを読み込みますが、スポーンツールでエージェントの種類を指定できないため、委任先にはプロンプト内で完全なブリーフィングを渡します。

Claude Code では、登録によって追加される内容を説明します。2 つのペルソナと 5 つの pstack-effort-<level> エージェントが追加され、これにより、このハーネスで記述された @effort をサブエージェントに適用できます。Claude Code へのインストール前に、手順 2 のとおり両方の設定レイヤーを読み、このハーネス向けに実行負荷が指定されているすべてのロールと、その実行負荷を列挙してください。エージェントが読み込まれれば、それらのロールは指定された実行負荷で動作し、それ以外のすべてのロールはセッションの実行負荷を維持することを伝えてください。roles の行と efforts の行は、ライブ読み込みの状況とは分けて報告してください。インストール結果で agents_directory: created と報告された場合、エージェントが読み込まれるのは新しいセッションからなので、ユーザーに新しいセッションを開始するよう伝えてください。それ以外の場合は、--disable-slash-commands を指定して起動したセッション、または --add-dir からディレクトリを取得したセッションを除き、実行中のセッションがエージェントを読み込みます。いずれの場合も、実行負荷が適用されると主張する前に、ライブカタログを確認してください。

ペイロードの準備状況、ネイティブファイルの状態、ライブエージェントの読み込み状況は、それぞれ分けて報告してください。ネイティブで利用可能だと主張する前に、指定された保存先を確認し、ライブエージェントカタログを調べてください。ファイルシステムの出力だけでは、有効化されたことは確認できません。Codex のプロジェクト登録には、プロジェクトの信頼が必要です。信頼設定を自動で編集してはいけません。登録を変更した後は新しいセッションを確認してください。ローダーの再起動が必要な場合は、その旨を伝え、読み込みが確認されるまでは完全なブリーフィングによる委任を使用してください。これらの確認事項は、以下のモデル選択とは分けて扱ってください。

0b. 構造化タスクツールを確認する

poteto-mode は、ツールが有効な場合、ハーネスの構造化タスクツールに作業リストを保持します。このスキルを実行する CLI がどれであっても、以下の両方のスイッチを確認し、それぞれがオンかオフかを報告してください。変更は次のセッションから適用されます。ユーザーが承諾してからファイルを編集してください。その後、既存のファイルにキーを追加し、それ以外のキーはすべて維持してください。

• Claude Code では、環境変数または ~/.claude/settings.json、.claude/settings.json、.claude/settings.local.json の env ブロックで CLAUDE_CODE_ENABLE_TODO_TOOLS が 1 に設定されている場合、または起動時に --allowedTools でタスクツールのいずれかを指定した場合、すべてのモデルでタスクツールが有効になります。スイッチがオフの場合、すべてのプロジェクトで有効にするには ~/.claude/settings.json に、現在のプロジェクトだけで有効にするには .claude/settings.local.json に "env": {"CLAUDE_CODE_ENABLE_TODO_TOOLS": "1"} を設定するよう勧めてください。また、settings.local.json を手動で作成する場合は、.gitignore にその行を追加する必要があることも伝えてください。さらに、ツール検索がオン（デフォルト）の場合、タスクツールは遅延読み込みされ、Sonnet は /poteto-mode の4回の実行すべてで作業リストを保持しませんでした。一方、各プレイブックのステップにつき1つのタスクを割り当てた場合は、ENABLE_TOOL_SEARCH=false で2回中2回とも保持しました。この設定により、2026-09 の 2.1.284 では、単純な初回ターンの入力トークン数が 25,770 から 45,907 に増加したため、選択はユーザーに委ねてください。
• Codex では、$CODEX_HOME または ~/.codex/ 配下の config.toml に [tools.update_plan] に続けて enabled = true が記述されている場合、プランツールが有効になります。Codex の公開設定リファレンスにはこのキーが記載されていませんが、同梱の codex-rs/core/config.schema.json では、0.158.0-alpha.2.1 時点で enabled のデフォルト値が false と定義されています。スイッチがオフの場合、この2行を設定するよう勧めてください。Codex は単独の update_plan = true を受け付けません。
• Hermes には、既知のスイッチはありません。変更するものはないと報告してください。
• Grok Build には todo_write ツールが同梱されており、既知のスイッチはありません。変更するものはないと報告してください。

0c. Claude Code のスキル一覧を確認する

ユーザーが Claude Code で pstack を実行するたびに、この確認を実行してください。Codex は agents/openai.yaml を通じて一部の pstack スキルが暗黙的に呼び出されるのを防ぎますが、Claude Code はこのファイルを無視します。オーバーライドがない場合、それらのスキルは完全な説明とともに一覧表示され、その説明から読み込まれます。~/.claude/settings.json に "skillOverrides": {"<skill>": "name-only"} がある場合、Claude Code は各スキルを名前だけで一覧表示します。その場合、ユーザーが /name と入力するか、pstack のスキルがエージェントにそのスキルの使用を指示したときに読み込まれ、説明から読み込まれることはありません。

ステップ 0a と同じ方法でインストール済みスキルのルートを解決し、次を実行してください。

python3 "${PSTACK_SKILLS_ROOT:?}/setup-pstack/scripts/skill-listing.py" check

失敗を示すシグナルは終了コード 2 です。設定ファイルが読み取り不能または不正な形式であるか、スキルのルートが誤っています。stderr の行を報告し、ファイルには手を加えないでください。終了コード 1 は一覧が古いことを示し、stdout の JSON に missing と extra のスキルが記載されています。終了コード 0 は最新であることを示します。kept_off のスキルがあれば、ユーザー自身がオフにした選択として報告し、それを指定する pstack スキルは読み込めないことを伝えてください。この確認ではユーザーファイルのみを読み取ります。プロジェクトの .claude/settings.json または .claude/settings.local.json に pstack スキルの skillOverrides エントリがある場合は、プロジェクト側のエントリがユーザーファイルを上書きする可能性があるため、それも報告してください。

一覧が古い場合は、install を提案し、何が変更されるかを伝えてください。ユーザーが承諾した後に限り、check を install に置き換えて同じコマンドを実行してください。これにより、各 missing スキルに name-only が設定され、on または user-invocable-only の値は置き換えられます。対象セットに含まれない pstack スキルの name-only エントリは、ユーザーが記述したものであっても削除されます。それ以外のキーと、ユーザーの off エントリはすべて維持されます。また、変更されるのは pstack 独自のスキルのみで、他のスイートのスキルのエントリはそのままです。added、removed、最終的な state を報告し、変更は次のセッションから適用されることを伝えてください。

0d. Codex サブエージェントを確認する

Codex では、pstack は spawn_agent を通じてネイティブにロールを起動します。このツールを利用できない場合、pstack-harness スキルは codex exec サブプロセスにフォールバックするか、アームを一度に 1 つずつインラインで実行します。インラインレビューは独立したレビューではありません。このスキルが Codex で実行される場合、またはユーザーが pstack をそこで実行する場合は、この確認を実行してください。

セッションで spawn_agent を利用できるかどうかは、設定だけでは決まりません。Codex 0.160.0 では、選択したモデル独自のマルチエージェント設定、起動フラグ、スポーンの深さ、このスキルから読み取れない設定レイヤーにも左右されます。そのため、設定から分かるのは兆候のみで、答えが分かるのは Codex セッション内だけです。

• Codex セッション内では、答えは spawn_agent を呼び出せるかどうかです。セッションでツールがツール検索の後に表示される場合は、利用できないと判断する前に検索してください。見つからない場合は、除外できない原因を列挙してください。

  • 設定キー
  • セッションの起動時に指定された -c フラグ
  • 選択したモデル
  • スポーンの深さ
  • 読み取れない設定レイヤー

  証拠がない限り、原因を 1 つに決めつけないでください。

• 設定上の兆候。 ユーザーが Codex を起動する環境で、プロジェクトのルートから codex features list を実行し、ラッパーの CODEX_HOME があればそれも含めて、multi_agent と multi_agent_v2 の行を報告してください。次に、codex features list では報告されないため、$CODEX_HOME または ~/.codex/ の config.toml と、プロジェクトが信頼されている場合はプロジェクトの .codex/config.toml から、[agents] の enabled を読み取ってください。これらはスポーンの可否を断定するものではなく、兆候として報告してください。

• codex が PATH にない場合（このスキルが別の CLI から実行されている場合や、Codex がアプリにバンドルされている場合など）は、設定上の兆候を未確認として報告してください。ライブセッションで確認できた結果は、そのまま有効です。

読み取ったファイル内のキーは原因の可能性を示すだけであり、確定した原因ではありません。multi_agent_v2 や読み取れないレイヤーによって上書きされる可能性があるためです。編集を提案するのは、Codex セッションで spawn_agent が利用できないことを確認し、かつ設定ファイルに可能性のある原因が示されている場合に限ってください。

• 読み取ったファイルで [agents] の enabled = false が設定されており、multi_agent_v2 の行が false で、かつ優先順位がより高い読み取り可能なファイルに true の設定がない場合は、その行の削除または true への変更を提案してください（信頼済みプロジェクトのファイルはユーザー設定より優先されます）。読み取り可能なレイヤーによって上書きされている場合、または行が未確認の場合は、そのキーを未確認として報告し、変更を提案しないでください。Codex 0.160.0 では、multi_agent の行が true でも、このキーによって spawn_agent は利用できなくなります。multi_agent_v2 が有効な場合、このキーはスポーンを妨げないため、変更を提案しないでください。
• 両方の機能の行が false で、読み取ったファイルに機能を無効にする設定がある場合（[features] の multi_agent = false、ドット区切りの features.multi_agent = false、または従来の [features] の collab = false など）は、そのファイルで true に設定するよう提案してください。ユーザー設定にこのキーがある場合は、codex features enable multi_agent で 3 つの設定のいずれも修正できます。読み取ったファイルに無効化する設定がない場合、原因は読み取れないレイヤーにあるため、変更を提案する代わりにその旨を明記してください。

[features]
multi_agent = true

ユーザーが同意してからファイルを編集し、他のキーはすべてそのままにしてください。変更は次のセッションから反映されます。確認できるセッションがない場合は、兆候と考えられる原因を報告し、スポーンの可否は未確認であると伝え、変更を提案しないでください。

0e. リポジトリの PR テンプレートを設定する

Git リポジトリを完全に設定するには、references/pr-template.md の手順に従ってください。既存のリポジトリテンプレートと明示的な選択は維持してください。テンプレートがない場合は、同梱の poteto テンプレートをインストールし、no-mistakes が設定されている場合は pr.template でそれを選択してください。変更したファイルと、信頼済みデフォルトブランチでの有効化が保留中かどうかを報告してください。リポジトリ外の場合、または依頼がモデル、予算、ホスト設定の変更のみの場合は、この手順を省略してください。

1. 利用可能なモデルと推論レベルを検出する

セッションのスポーン機構が受け付けるモデル値と、各スポーンで受け付ける推論レベル値を列挙します（機構を確認するには pstack-harness スキルを使用します）。Claude Code では、スポーンごとの推論レベルは、ライブカタログに記載されている pstack-effort-<level> エージェントのレベルです。推論レベルエージェントが読み込まれていない場合は、該当するものはありません。これが信頼できる情報源です。CLI にも、codex debug models や grok models のように、ユーザーが利用できるモデルを一覧表示する API やコマンドがある場合は、網羅性を高めるため、そちらを優先します。何も検出できない場合は、利用可能なスラッグをユーザーに貼り付けてもらいます。利用可能であることを確認していない実際のスラッグは、決して記載しないでください。エイリアス inherit-parent と auto は、検出されたスラッグではなくても常に有効です。

2. 現在の状態を読み込む

デフォルトのマッピングは、このスキルと同じ場所にある examples/pstack-models.md です。設定の両方の階層が存在する場合は、ワークスペースの .agents/pstack-models.md、次に ~/.agents/pstack-models.md を読み込み、ハーネスのセクションも含めます。各ロールの行と、設定対象のファイルにある # budget 行を現在の選択として扱います。--resolve --harness <this CLI> を実行すると、各ロールがこの環境でどのように実行されるかを表示します。それ以外の場合は、まずデフォルトの設定を使用します。リポジトリ単位の上書きをユーザーが求めていない限り、設定対象はユーザーレベルのファイルです。モデル設定の文法に従って、予算とマッピングの手順を通じて trail reviewer step の設定を保持します。examples/pstack-models.md にないロールの行（例：how critics）は削除します。

3. 予算を確認し、マッピングして確定する

（a）予算を尋ねます。 自由入力よりも AskQuestion を優先します。以下の5つの選択肢を、これらのラベルどおりに提示し、ファイルに現在の予算が記録されている場合はその予算名も伝えます。ファイルがない場合は、default を選ぶと提供時のデフォルト設定が維持されると説明します。最初の選択肢はポート追加分で、残りの4つはアップストリームと同じです。

• default — keep as written
• unlimited — max reasoning
• large — xhigh reasoning
• medium — high reasoning
• small — medium reasoning

Claude Code では、default — keep as written を「明示的に推論レベルが書かれていないロールは、セッションの推論レベルで実行されます」と説明します。また、推論レベルエージェントが読み込まれると、予算のサフィックスはセッションの推論レベルより高くも低くも設定できることを、質問時に伝えます。

（b）予算を適用します。 examples/pstack-models.md から作業用の表を作成します。再実行時は、ユーザーがモデル、推論レベル、リスト、エイリアス（inherit-parent、auto）、またはハーネスのセクションを変更したロールを保持します。default は予算を適用しません。明示的に記述された @effort サフィックスはすべてそのまま維持し、サフィックスがない項目はreferences/models-config.mdに記載された推論レベルのポリシーに従います。Claude Code では、このポリシーはセッションの推論レベルです。unlimited、large、medium、small を選択した場合は、パネルの項目やハーネスのセクションも含め、すべての実際の項目の @effort をそれぞれ max、xhigh、high、medium に設定し、サフィックスがない項目には追加します。ステップ4のリントでその推論レベルがモデルに対して拒否された場合は、指定レベル以下でモデルが対応する最も高い推論レベルを使用します。リントでモデルを分類できない項目は、記述済みの推論レベルを維持するか、サフィックスなしのままにし、ステップ（c）で変更しなかった項目として説明します。auto@max のようにサフィックスが記述されたエイリアスも、Codex がエイリアスのサフィックスに対応しているため、同じルールでサフィックスを書き換えます。inherit-parent または auto のみの項目は変更しません。どの予算も、モデルやリストの長さは変更しません。そのため、small は fable を fable@medium に、gpt-6-sol@max を gpt-6-sol@medium に変更します。また、unlimited は両方を fable@max と gpt-6-sol@max に戻します。Claude Code では、推論レベルエージェントが読み込まれている場合に限り、明示的なサフィックスが適用されます。ライブカタログにそれらのエージェントがない場合は、その旨を伝えます。同じファイルを読み込む Codex と Hermes には引き続きサフィックスが適用されます。また、この環境のサブエージェントは、エージェントが登録され、カタログに記載されるまでは、セッションの推論レベルで実行されます。 （c）役割を表示して確認します。 ファイルは複数の CLI で共有されるため、このハーネスでは検証できない値も誤りではなく、別のハーネスで選択されたものです（ここでは inherit-parent として読み取られます）。このハーネスの各役割とモデル、effort をすべて表示し、検出されたセットに含まれない値には、変更しない限りそのまま保持されることを示す「（別のハーネス用に設定 — 変更しない限り保持）」を付けます。Claude Code では、effort が記述されていない役割は session として表示し、ライブカタログにエージェントがない場合は、記述された effort に「（effort エージェントが読み込まれるまで無効）」を付けます。また、ステップ 2 で削除された各行も一覧表示します。そのまま受け入れるか、特定の役割を変更するかを尋ね、選択肢として検出されたモデルに inherit-parent と auto を加えて提示します。どちらも「この役割は親チャットのモデルで実行されます」という意味で、Auto ユーザーが Auto のまま利用できる設定です。自由記述より AskQuestion を優先します。パネル役割（arena runner、architect runner、interrogate reviewer）では値はリストで、エイリアスの項目も含め、項目ごとにサブエージェントが 1 つ実行されるため、リストの長さが実行数になります。arena cross-judge pool もリストですが、Arena は可能であれば、親のモデルとはモデルファミリーまたは機能ティアが異なる値を 1 つ選択します。swarm workers は、レースまたは比較で各アームに別のモデルが割り当てられない限り、swarm スキルに従って、何かを実行する swarm worker をすべて実行します。trail reviewer は、作業の証拠を提示するレビューアーと、swarm の監査レーンを含む、独立したすべての判定およびレビューを実行します。routine は、呼び出し元のスキルで別の役割が指定されていない限り、縮約された所見を返すすべての読み取り専用スキャン、解析、または監視サブエージェントを実行します。その適用範囲については、models config reference に従います。モデルと effort は作業用テーブルから表示します。レビューアーの解決とモデルのオプトアウトについては、models config rule 7 に従います。また、作業が実行される場合に起動するレビューアーも表示します。feature と refactoring を解決し、出力された各アームから <model>@<effort> を 1 つずつ作成します。auto の出力のように、モデルが inherit-parent の場合はセッションモデルを使用します。セッションモデルとは、システムプロンプトまたはこの CLI の設定でセッション用に指定されているモデル ID で、たとえば claude-opus-5-5 です。effort が inherit-parent の場合は、セッションの effort を使用します。不明な場合は @<effort> を省略します。auto@max の max のように、記述された effort はそのまま保持します。これらの置換後に重複を削除します。続いて、残った値ごとに、1 回の実行につき --work-model フラグを 1 つだけ指定して、python3 <this skill's directory>/scripts/check-models-config.py --resolve --harness <this CLI> --work-model '<model>@<effort>' "trail reviewer" を実行します。リゾルバーは最後のフラグだけを保持するためです。--work-model の指定で実行が終了コード 2 になった場合は、Spawn a role step 2 に従って値を修正し（たとえば [1m] サフィックスを削除）、再実行します。それでも終了コード 2 になる場合は、--work-model を付けずに実行し、リゾルバーがセッションモデルを拒否したためプレビューにステップが表示されないことを伝えます。各実行の行末には when work runs on <value> を付けます。ここで <value> は実際に渡した値です。モデルがセッション由来の場合は、その後に (session model) を追加します。アームに step がある場合は、記述値とステップ後の値を併記します。たとえば trail reviewer: gpt-6.1-sol@xhigh → gpt-6-astra@high when work runs on gpt-6-sol@high のようにし、その注記も伝えます。それ以外の場合はアームのみを表示します。effort と pin の動作については、models config rule 7 を使って説明します。レビューアーを固定したい場合に限り、trail reviewer step: off を提示します。実行 ID の開示については、Spawn a role に従います。default は、スキルで役割が指定されていない spawn に適用される項目です。ユーザーがマッピングされていない spawn に特定のモデルを使いたい場合を除き、inherit-parent のままにします。

4. 検証する

書き込む前に、書き込もうとしているファイルに対して lint を実行します：python3 <this skill's directory>/scripts/check-models-config.py <file>。error: の行（不明なロール、不正な effort、そのモデルがサポートしていない effort、ロールまたはセクションの重複、## claude-code の下にある none または ultra）があれば、書き込みを中止して該当行を修正し、再実行します。notice: の行は max と ultra の指定、および Claude Code がセッションの effort として実行するフラット行の none または ultra を示します。それぞれについてユーザーに読み上げ、高コストのティアや Claude Code のフォールバックが選択肢であることを伝えます。新たに選んだ実際のスラッグはすべて、検出されたセットに含まれている必要があります。inherit-parent と auto は常に検証に合格し、別のハーネスから引き継いだ値は対象外です。選んだ実際のスラッグが利用できない場合は、中止してもう一度ユーザーに確認します。lint に合格したら、それぞれのロールが何を実行するか、ここでユーザーに示します。ユーザーファイルの場合は、プロジェクトルートから python3 <this skill's directory>/scripts/check-models-config.py --resolve --harness <this CLI> --user-file <file> を実行します。これにより、そこにあるワークスペースファイルも適用されます。リポジトリ単位のオーバーライドの場合は、ドラフトを <temp>/.agents/pstack-models.md にコピーし、代わりに --project <temp> を指定して、実際のユーザーファイルをそのまま残します。その後、このファイルに対してステップ 3c が渡す各 --work-model の値ごとに "trail reviewer" を実行します。1 回の実行につき値は 1 つとし、ステップ 3c の説明どおり各行を示して、書き込む前にその行が何をするかユーザーが確認できるようにします。

5. 設定を書き込む

書き込み先は ~/.agents/pstack-models.md です。リポジトリ単位のオーバーライドをユーザーが求めた場合は、ワークスペースの .agents/pstack-models.md が書き込み先になります（このリポジトリでユーザーが固定したいロールだけを書き込みます。ワークスペースの各行はユーザーレベルの設定を上書きします）。ワークスペースファイルの # budget 行が対象とするのは、そのファイルに記述されたロールだけです。引き続き ~/.agents/pstack-models.md から解決されるロールは、そのファイルの予算設定を引き継ぎます。ファイルツールで書き込み先に書き込めない場合（ハーネスがワークスペース内への書き込みに制限されている場合）は、次の順にフォールバックします。シェルツールで書き込む。それもできない場合はワークスペースファイルを書き込み、~/.agents/ にコピーされるまでは設定がプロジェクトローカルであることを伝える。それもできない場合は、保存用の最終的な内容をユーザーに出力します。書き込みを黙って省略してはいけません。

選択したラベルとその目標 effort を記載した # budget 行と、ロールごとの行を 1 行ずつ書き込みます。poteto-mode が使用するものと同じラベルを使います。このスキルと同じ場所にある examples/pstack-models.md を元にし、ヘッダーコメントはそのまま残して、予算行の値を置き換えます。再実行しても冪等性が保たれるよう、ファイル全体を書き換えます。ただし、ユーザーが変更していない既存の行はすべて引き継ぎます。これには、このハーネスでは検証できないセクションや値も含まれます。避けるべき唯一の失敗は、別の CLI の選択を inherit-parent で上書きすることです。ステップ 2 で削除した廃止済みロールの行は含めません。ハーネス固有の選択は、そのハーネスの ## <harness> セクションに記載し、ほかの CLI 向けのフラット行はそのまま残します。形式の例：

# budget: default (keep as written)
feature, refactoring: sonnet
bug-fix: sonnet

## codex
feature, refactoring: gpt-6-sol@high
bug-fix: gpt-6-sol@xhigh

6. 確認する

設定を書き込んだことと、スキルが次回の実行時にその設定を読み込むことをユーザーに伝えます。このスキルを再実行すると、設定が更新されます。

7. 検証スキルを提案する（任意）

プロジェクトに、実際のアプリを操作して動作を確認する方法（verify-* スキル、または既存のハーネス）があるか確認します。ない場合は、一度だけ次のように提案します：「エージェントがユーザーと同じようにアプリを操作して変更が機能することを確認できる、プロジェクトローカルの検証スキルが必要ですか？ /create-verification-skill で生成できます。」希望する場合は、create-verification-skill スキルを使用します。希望しない場合は、無理に勧めず次に進みます。

8. 形式検証スキルを提案する（任意）

プロジェクトにすでに形式検証スキル（モデルチェッカー、証明、または別の検証ツールをコードに対して実行するプロジェクトスキル）があるか確認します。ない場合は、一度だけ次のように提案します。「テストでカバーされるケースだけでなく、対象範囲内のあらゆるケースでコードの重要な特性が成り立つことをエージェントが証明できるよう、形式検証スキルを作成しますか？ /create-formal-verification-skill を使って作成できます。」はいの場合は、create-formal-verification-skill スキルを使います。いいえの場合は、無理に勧めず次に進みます。