| name | llm-friendly-context |
| description | 入力・出力・成功基準・決定事項・未解決条件を明確化し、下流エージェントが推測せず実行できるようにする。LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述または改訂する時に使用。 |
LLM-Friendly Context
目標は、下流が安定して実行できるようにすることである。次のエージェントが、何を読み、何をし、何をもって成功とし、いつ停止・エスカレーションするかを把握できる状態を目指す。
本スキルはLLM向け出力（プロンプト、ハンドオフ、生成物）の明確さを扱う。どのドキュメントを作成するか、その必須構造が何かは定義しない。それはdocumentation-criteriaの責務である。
中核ルール
-
肯定形で実行可能な指示を使う
- 次のエージェントが何をすべきかを述べる。
- 品質ポリシーは肯定的な基準に変換する。
- 例: 「文書化された互換ケース全体で、既存の公開API挙動を維持する」
-
曖昧な指示を具体化する
- 主観的な語を、観察可能な条件・パス・コマンド・スキーマ・例・判断ルールに置き換える。
- 次のエージェントに判断を委ねてしまい、明確化が必要になりやすい語:
appropriate、proper、related、existing behavior、optional、as needed、if needed、per convention、未解決の代替案、TBD、placeholder。
-
出力構造を指定する
- 必須のセクション・フィールド・表のカラム・JSONキー・チェックリスト項目を定義する。
- ハンドオフでは、生成した成果物のパスと、呼び出し側が確認すべき正確なステータスフィールドを含める。
-
必要なコンテキストを与える
- 目的・出典となる成果物・厳格な制約・合意済みの決定・未解決条件を含める。
- 大まかなモジュール名より、具体的なファイルパスとセクションヒントを優先する。
-
複雑な作業を検証可能なステップに分解する
- 目的が3つ以上、または逐次的な依存がある作業は、順序付きのステップに分割する。
- 各ステップには、完了を証明する根拠を示すチェックポイントを設ける。
-
不確実性を明示的に許可する
- 出典が欠落・矛盾・検証不能な場合は、その不確実性と必要なエスカレーションを述べる。
- ビジネス・プロダクト・セキュリティ・互換性に関する未知の決定は、解決に必要な入力とエスカレーション条件を付したブロッキングな未解決項目として記録する。
- ブロッキングな未解決項目は、成果物を問わず一貫した形式で書く:
Unresolved: <必要な決定> — required input: <解決に必要な入力（必要なら確認先も）> — escalation: <次のエージェントが推測せず停止すべき条件>。
-
制約を比例的に保つ
- 曖昧さを減らす、または実在の要件を保つ制約のみを追加する。
- 対象アクション・コンテキスト・成功基準が既に明確な単純な下流タスクは、軽量なまま保つ。
書き換えパターン
プロンプト・ハンドオフ・成果物を完成とみなす前に、以下の書き換えを適用する。
| 曖昧な形 | 書き換え後 |
|---|
未解決の選択として使われる optional | 必須・省略・特定条件下でのみ必須、のいずれか |
| 次のエージェントが選ばねばならない複数の代替案 | 選択した選択肢、または決定的な判断ルール |
as needed / if needed | 発動条件と必要なアクション |
per convention | 従うべきファイル・関数・テスト・文書化された規約 |
related files | 具体的なパス・glob・サーチヒント |
existing behavior | 維持すべき観察可能な挙動・出典ファイル・テスト・APIレスポンス・UI状態 |
placeholder | 正確な暫定値/挙動・許容される依存・検証の期待値 |
必須情報のプレースホルダとして使われる TBD | required inputとescalation conditionを付したブロッキングな未解決項目（判明していればownerも） |
appropriate / proper | 測定可能な基準またはチェックリスト |
ハンドオフチェックリスト
プロンプトや成果物を別のエージェントに渡す前に確認する:
生成物チェックリスト
生成ドキュメントを記述・確定する前に確認する:
