principle-guard-the-context-window

コンテキストウィンドウを守る

コンテキストウィンドウは有限で、セッション中に補充されません。すべてのトークンは、そのコストに見合う価値が必要です。

理由： コンテキストのオーバーフローは推論の質を低下させ、圧縮によるアーティファクトを生み、進行を妨げます。

パターン：

• 大きなペイロードを切り分ける。 冗長な出力、スクリーンショット、大きなドキュメントはサブエージェントに渡します。メインコンテキストには生データではなく要約を入れます。簡潔な調査結果を返す読み取り専用のスキャンや解析には、呼び出し元のスキルで別のロールが指定されていない限り、routine ロールを使います。ロールの決定には、pstack-harness スキルの Spawn a role セクションを参照します。
• 頻繁に使う内容はインラインに置く。 呼び出しのたびに使うテンプレートやリファレンスは、読み込みのたびにコストがかかる別ファイルではなく、スキルファイルに含めます。
• フェーズの規模を決め、範囲を制限する。 フェーズごとのファイル数を制限し、ターン数の予算を設定して、仕組みにかかるコストを考慮します。
• 報告は簡潔にする。 サブエージェントの報告を次のステップに使う場合は、詳しい報告の保存場所（サブエージェントが書き込むファイルまたは PR）を指示に明記し、判定またはステータス行、ブロッカーの有無、そのパスまたは URL だけを返すよう求めます。ブロッカーに対処する場合に限り、詳しい報告を読みます。how の説明、why の統合、trail reviewer の指摘、arena cross-judge のスコアなど、サブエージェントの出力そのものを引き継ぐ場合は、全文を返してもらいます。
• リードの読み込み量を予算化する。 約150行を超えるファイルやコマンド出力は、自分で編集する場合を除き、サブエージェントに渡します。コマンド出力は head、tail、grep、または --jq で絞り込んでから読み込みます。編集する直前でない限り、how パスですでに内容を整理したファイルを読み直しません。Code review の変更ファイル、Eval の候補出力、show-me-your-work のトランスクリプト監査など、プレイブックやスキルの手順で自分に割り当てられた読み込みは例外です。
• プレイブックは手順だけを読む。 作業リストを開くときは、プレイブック全体ではなく、手順1より前の説明文と、インデントされたサブ項目を含む番号付き手順を表示します（awk '/^[0-9]+\. /{p=1} !p && !/^#/ && NF {print; next} p && /^[^ ]/ && !/^[0-9]+\. /{exit} p' <playbook>）。手順1より前の説明文も、作業リストの最初の項目です。その説明文でプレイブック全体を読むよう指示されている場合は、全文を読みます。