llm-friendly-context

# LLM-Friendly Context 目標は、下流が安定して実行できるようにすることである。次のエージェントが、何を読み、何をし、何をもって成功とし、いつ停止・エスカレーションするかを把握できる状態を目指す。 本スキルはLLM向け出力（プロンプト、ハンドオフ、生成物）の明確さを扱う。生成物の種類と、生成物固有のテンプレートまたはセクション契約は呼び出し元が渡す。本スキルは、渡された契約を後続エージェントが実行できる形にする。 実行中のワークフローが宣言した入力契約は、その担当スペシャリスト向けに既に最適化されている。名指しされたフィールドと宣言された値の形式は保持し、それらのフィールドと値からハンドオフを組み立てる。以下の一般的なプロンプト構成ルールは、入力契約が存在しない場合にのみ適用する。生成物向けのルールは生成物に適用する。 ## 中核ルール 1. **肯定形で実行可能な指示を使う** - 次のエージェントが何をすべきかを述べる。 - 品質ポリシーは肯定的な基準に変換する。 - 例: 「文書化された互換ケース全体で、既存の公開API挙動を維持する」 - 禁止形を残すのは、それが不可逆な境界または出荷済みの契約を守る場合に限る。その場合は、守られる条件と許容されるアクションを併記する。 2. **曖昧な指示を具体化する** - 主観的な語を、観察可能な条件・パス・コマンド・スキーマ・例・判断ルールに置き換える。 - 次のエージェントに判断を委ねてしまい、明確化が必要になりやすい語: `appropriate`、`proper`、`related`、`existing behavior`、`optional`、`as needed`、`if needed`、`per convention`、未解決の代替案、`TBD`、`placeholder`。 3. **出力構造を指定する** - 必須のセクション・フィールド・表のカラム・JSONキー・チェックリスト項目を定義する。 - ハンドオフでは、生成した成果物のパスと、呼び出し側が確認すべき正確なステータスフィールドを含める。 4. **必要なコンテキストを与える** - 目的・出典となる成果物・厳格な制約・合意済みの決定・未解決条件を含める。 - 大まかなモジュール名より、具体的なファイルパスとセクションヒントを優先する。 - 参照は、次のリンクがスコープ内の判断を変えうる間はたどる。既に決まっている内容を確認するだけになった時点で止める。 5. **複雑な作業を検証可能なステップに分解する** - 目的が3つ以上、または逐次的な依存がある作業は、順序付きのステップに分割する。 - 各ステップには、完了を証明する根拠を示すチェックポイントを設ける。 6. **不確実性を明示的に許可する** - 出典が欠落・矛盾・検証不能な場合は、その不確実性と必要なエスカレーションを述べる。 - ビジネス・プロダクト・セキュリティ・互換性に関する未知の決定は、解決に必要な入力とエスカレーション条件を付したブロッキングな未解決項目として記録する。 - ブロッキングな未解決項目は、成果物を問わず一貫した形式で書く: `Unresolved: <必要な決定> — required input: <解決に必要な入力（必要なら確認先も）> — escalation: <次のエージェントが推測せず停止す...