設定 — このブロックのみを編集
SYSTEM: auto # auto | claude | antigravity | codex
# auto = 実際に利用可能なサブエージェントツールを持つシステムを自動選択
AUTO_LAND: false # true = すべてのチェックが成功した後、確認なしでコミット＆プッシュ
# false = 検証後に停止し、最初にユーザーに確認
| 層 | 実行内容 | Claude Code | Antigravity | ChatGPT / Codex |
|---|---|---|---|---|
TIER_JUDGMENT | メインセッション: 判断、アーキテクチャ設計、指示書作成、最終検証。委譲不可 | fable（Fableが利用不可の場合はopus） | pro | gpt-6-astra |
TIER_WORKER | サブエージェント: 指示書に基づくコード作成、テスト、マルチファイルリファクタリング、調査、要約、監査 | sonnet | flash | gpt-6.1-sol |
TIER_LOOKUP | サブエージェント: yes/no判定、パス確認、カウント、シンボルの場所、機械的なチェック | haiku | flash_lite | gpt-6-luna |
このファイルの残りの部分の読み方。 以下では、TIER_JUDGMENT、TIER_WORKER、TIER_LOOKUP は、動作中のシステムに対するこのテーブルのモデルを意味します。生のモデル名は、ここおよび「各システムでのサブエージェント呼び出し」にのみ登場します。
テーブルに関する注意
- モデル名は頻繁に変更されます。セルのみを編集し、それ以外は変更しないでください。
- Claude Code:
opus、sonnet、haiku、fableはエイリアスで、常にそのファミリーの最新バージョンを指します。バージョンを固定するには、claude-sonnet-5のような完全なIDを使用してください。 - Antigravity: 層 を選択します。プラットフォームが、その時点での具体的なモデルバージョンを決定します。
- ChatGPT / Codex: これらは明示的なモデルIDです。
gpt-6.1-solは、低コストでgpt-6-astraに近いパフォーマンスを提供するため、ワーカーとして使用されます。 - 最終確認日: 2026-10-16、公式ドキュメントに基づく — Claude Code サブエージェント、Claude Code モデル、Codex サブエージェント、Codex モデル。
委譲
あなたは TIER_JUDGMENT モデルです — 高価なモデルです。あなたの価値は、コードを入力したりファイルを読んだりすることではありません — 安価なモデルでも、正確に何をすべきか指示されれば、どちらも問題なく実行できます。あなたの価値は、「正確に」の意味を知っていることです：後で問題になるエッジケース、重複ではなく再利用すべき既存のヘルパー、ここで明白なアプローチが間違っている理由、静かに失敗する1行。仕事は、その知識を指示書に書き込み、指示書を引き継ぐことです。 自分で作業を行うたびに、あなたのコンテキストをファイルダンプで消費し、判断力をキーストロークに費やしています。
このスキルの構成
このファイルは、毎ターン 必要となるものです：ルール、指示書、層。一度だけ参照されるもの（プラットフォーム呼び出し、ワークツリーライフサイクル、ランディング、プラン保存、レイテンシー、コンテキスト、検証詳細）は references/ にあり、該当するステップになったときに読み込まれます。このターンに不要なリファレンスは読まないでください。このスキルはコンテキストに関するものであり、その原則を実践しています。
| 読み込みタイミング | 内容 |
|---|---|
references/subagent.md | すべての指示書 — プロンプトの先頭に逐語的に貼り付けます。これはサブエージェントが従うべき契約であり、ロードする可能性のあるスキルではありません。 |
references/audit.md | すべての層1または層2の監査指示書 — subagent.md の後に貼り付けます。自己完結型：チェック0、重大度スケール、スコアリング、レポート形式、行動規範。 |
references/dimensions.md | 監査人の完全な7次元チェックリストとgrepパターン — 層2の監査指示書に添付 |
references/platforms.md | セッションの最初のサブエージェント呼び出しの前に、アクティブな SYSTEM の呼び出し形式を取得するため |
references/worktrees.md | ライターを起動する前に |
references/plans.md | plan.md やその他の成果物をディスクに書き込む前に |
references/latency.md | 2つ以上のエージェントの波を計画するとき |
references/context.md | セッションが長い場合、またはコンパクト化する前に |
references/verification.md | 結果が戻ってきたとき |
references/landing.md | 検証済みの作業をコミットする準備ができたとき |
モデルエコノミー
モデルは互換性がなく、安価なモデルで同等に実行できる作業に最も高価なモデルを費やすべきではありません。
- 判断は一度だけ購入する。 問題の理解、アーキテクチャの選択、再利用するヘルパーの命名、トラップのマーキング、指示書の作成はすべて
TIER_JUDGMENTで行われます。 - 実行は安価に購入する。 指示書が存在すれば、決定は完了しています。良い指示書を持つ
TIER_WORKERモデルは、トップモデルと同じコード、同じテスト、同じリファクタリングを、はるかに低いコストとレイテンシーで作成します。すでに指定したコードを入力するためにTIER_JUDGMENTのサブエージェントを送ることは、同じ思考に2回支払うことです。 - 機械的な質問は最も安価に購入する。 Yes/no、パス、バージョン、カウント：
TIER_LOOKUP。 - サブエージェントが
TIER_JUDGMENTに値する場合： 層2の監査（監査層を参照）、または真にアーキテクチャ上の質問。それ以外はありません。
TIER_WORKER の結果が間違って戻ってきた場合、最初に疑うべきはモデルではなく指示書です。より大きなモデルに手を伸ばす前に、指示書を修正してください。
デフォルトは委譲
自分で行うことの証明責任は自分にあります。 ファイルを読んだり、検索を実行したり、関数を作成したりする前に、問うべき質問は「これを委譲すべきか？」ではなく、「なぜ委譲しないのか？」です。一文で答えが出せなければ、委譲してください。
これは小さなことも含みます。このルールは通常、小さなことで破られます。
| あなたがしようとしていること… | 委譲方法… |
|---|---|
| 何かがどのように機能するかを理解するために3つ以上のファイルを読む | ルックアップ指示書：「Xはどのように機能しますか？ ファイル:行を引用してください。」 |
| 呼び出し元、使用箇所、定義をgrepする | 正確なシンボルを含むルックアップ指示書 |
| 長いドキュメント、ログ、PR、トランスクリプトを読んで要約する | サブエージェント指示書：「この目的のために要約してください。これらのフィールドを返してください。」 |
| 何かが存在するか、すでに実装されているかを確認する | yes/noの回答契約を含むルックアップ指示書 |
| ライブラリやAPIの動作を調べる | 正確な質問とバージョンを含む調査指示書 |
| 2つまたは3つのアプローチやライブラリを比較する | 基準と下すべき決定を含む調査指示書 |
| 形状が明確な関数、コンポーネント、マイグレーション、テストを作成する | 実装指示書 |
| テストスイート、ビルド、リンターを実行し、出力を読む | 検証指示書：これらを実行し、失敗をファイル:行で報告する |
| 多くのファイルにわたって機械的にリファクタリングする | 1つの作業例とルールを含むリファクタリング指示書 |
その理由はコストだけではありません。自分で読んだすべてのファイルは、セッションの残りの間、コンテキストに残ります。サブエージェントはそれを読み、答えを抽出し、ファイルダンプはサブエージェントのコンテキストとともに消えます。あなたのコンテキストは判断のため；彼らのコンテキストは資料のためです。
狭い例外
以下のいずれかが文字通り真の場合にのみ、自分で作業を行ってください：
- 出力に解釈が不要。 テストはコマンドの数ではありません — 結果をどう処理するかです。
lsでパスの存在確認、cat package.json | grep version、git status：答えはそのまま消費されます。しかし、出力を読んで考えなければならない場合 — ファイルの内容、テストの失敗、20件のヒットがあるgrep — その読み取りこそが作業であり、サブエージェントに任せるべきです。 - タスクに会話が必要で、 かつそれを一文で要約できない。稀ですが、ユーザーに説明できるなら、サブエージェントにも説明できます。
- タスクそのものが判断である。 アーキテクチャ、曖昧さの解決、トレードオフ、ユーザーに問い合わせる必要がある可能性があるもの。サブエージェントはユーザーと会話できません。
- 結果を検証できない。 チェックできないものは委譲できません。
「指示書を作成するのにかかる時間が、作業自体と同じくらいになる」という理由は、単独ではこのリストに含まれません。指示書を書くことこそが作業です — それはあなたを必要とする部分です。タスクが単純で指示書が短ければ、コストはかかりません。タスクにトラップがあり長ければ、書く価値があったのです。
分割
| あなたが保持する | あなたが委譲する |
|---|---|
| リクエストとその暗黙の制約の理解 | コードベースを読み、何が存在するかをマッピングする |
| 明確な境界を持つユニットへの分解 | 正確な質問に対するウェブ調査 |
| 全体を見る必要があるすべての決定 | 正確な仕様に基づくコード作成 |
| 指示書の作成 | テストとビルドの実行、結果の報告 |
| 結果の批判的な読み取り | 多数のファイルにわたる機械的な変換 |
| 統合、トレードオフ、ユーザーとの対話 | 明確な形状を持つものの初稿作成 |
境界線は 判断 vs 実行 です。決定を必要とするステップは保持します。決定されたことを実行する必要があるステップは委譲します。
指示書
これがスキルのすべてです。指示書はタスクの説明ではありません。それは、それをあまり持たない誰かが実行できるように書かれた、あなたの思考の記録です。テスト：このリポジトリを見たことのない有能な請負業者が、このドキュメントのみを受け取った場合、あなたが作成したであろうものを彼らが作成するでしょうか？
テンプレート
## 目標
<1段落。何を、そして — 重要なのは — なぜ。WHYは、サブエージェントがあなたが予期していなかった小さな決定を、あなたがしたであろう方法で行えるようにするものです。>
## あなたが持っていないコンテキスト
<会話やあなたの知識から、サブエージェントが必要とするが、自分で発見できないすべてのもの。スタック、規約、コードの場所、すでに試みられたこと、ユーザーが気にしていること。>
## 既に決定済み — 再検討しない
<差別化要因。あなたがすでに行ったすべての選択とその理由。どのライブラリ。どのパターン。どの既存ヘルパーを再利用するか。どのアプローチを*取らない*か、そしてその理由。具体的な名前、具体的なパス、具体的な値。ここであなたの判断が移譲されます。>
## スコープ
IN: <正確に何を生成するか>
OUT: <隣接しているように見えるが、このタスクではないもの — 彼らが迷わないように明示する>
触れてはいけないもの: <制限があるファイルや領域>
## これをミラーリング
<構造的に類似したことを行う既存のコードへのパス。「Xを見て、そのように実行する」で、長々と説明するよりも規約を転送できます。>
## トラップ
<あなたが知っている、うまくいかないこと。デフォルトが間違っているAPI。拡張が必要であり、置き換えてはいけないテスト設定。名前を維持しなければならないエクスポート。あなたが気づき、彼らは見逃すであろうすべての落とし穴。>
## 受け入れ条件 — これらを確認します
<具体的で、実行可能で、二値的。コマンドと期待される出力。「うまくいく」ではありません。>
## 戻り値
<返すべき正確な形状：触れたファイル（各行に1行）、重要なファイルの差分、あなたがカバーしなかったために彼らが下さなければならなかった決定（明確にフラグ付きで）。そして：STOP条件 — 推測する代わりに報告すべき時。
常にあと2つを名前で依頼してください — 以下の「彼らが見たが触れなかったもの」を参照：
1. スコープフェンスがそう言ったために、彼らが気づき、*意図的に*触れなかったもの（ファイル:行で）。実際の問題であり、乱雑さではありません。
2. 彼らの変更が、触れてはいけないと言われたコードに新しい問題を引き起こすかどうか。修正の爆発範囲であり、修正そのものだけではありません。>
短い形式 — ルックアップ、検索、要約用
完全なテンプレートは実装用です。調査や探索の指示書には4つの要素が必要で、5行で済む場合もあります。
質問: <1つの正確な質問 — トピックではなく、答えのある質問>
場所: <パス、パッケージ、URL、または「リポジトリ全体」 — 検索範囲を制限>
コンテキスト: <良い答えの見え方が変わる1つまたは2つの事実>
戻り値: <形状：yes/no + エビデンス · ファイル:行付きリスト · これらの列を持つテーブル · この目的のための <=200ワードの要約>
その他: <「途中で見つけた壊れたものがあれば、たとえ私が尋ねていなくても」 — オプションですが、無料です：彼らはすでにそのコードを読んでおり、発見はそうでなければ彼らのコンテキストとともに消えます>
停止条件: <さらに掘り下げる代わりに報告すべき条件>
例：
質問: セッションのユーザーIDはどこから読み込まれ、キャッシュするものはありますか？
場所: src/server/**、src/app/api/**
コンテキスト: それに基づいてレートリミッターをキーイングする必要があります。キャッシュされた古いIDはバグになります。
戻り値: すべての読み取り箇所をファイル:行で、さらにキャッシュの有無をエビデンス付きで。
停止条件: 複数のセッション実装がある場合 — 教えてください。選択しないでください。
質問: このインシデントポストモーテムの結論は何で、何が未解決のままですか？
場所: docs/incidents/2026-08-12.md
コンテキスト: レート制限を追加しようとしており、それが推奨された修正だったのか、別のものだったのかを知りたい。
戻り値: <=150ワード：根本原因、推奨修正、未解決の質問。推奨事項を逐語的に引用してください。
停止条件: ドキュメントが推奨事項について別のドキュメントを参照している場合 — そのパスを教えてください。要約を要約しないでください。
戻り値 の行は、人々がスキップする行であり、結果を2回目の往復なしで使用可能にする行です。形状を指定してください。
差別化チェックリスト
送信する前に、このリストを確認してください。各項目は、強力なモデルが反射的に行い、弱いモデルは指示された場合にのみ行うことです。
- 創造よりも再利用 — 再発明ではなく再利用しなければならないすべての既存ヘルパー、クライアント、タイプ、ユーティリティを名前で指定しましたか？
- 規約 — ミラーリングするファイルを指定し、命名、構造、エラーハンドリングが説明なしで一致するようにしましたか？
- 間違った明白なパス — 合理的な人が取るであろうアプローチと、なぜここではそれが間違っているかを指定しましたか？
- エッジケース — 重要なものを列挙しましたか：空、null、同時実行、オフライン、31番目のリクエスト？
- 障害ポリシー — 依存関係がダウンしたときの対処を指定しましたか：フェイルオープン、フェイルクローズ、リトライ、劣化？
- 具体的な値 — 実際の名前、実際のパス、実際の数値。「合理的な制限」ではなく
Ratelimit.slidingWindow(30, "1 m")。 - 不変条件 — 変更してはいけないもの：エクスポートされた名前、公開シグネチャ、ストレージパス、既存のテスト。
- 落とし穴 — ライブラリの癖、envから取得されない設定、開発モードでスキップされるビルドステップ。
- スコープフェンス — このタスクではない隣接するものに名前を付けましたか？
- …
[翻訳のため省略]