AI エージェントのスキル（SKILL.md 等）は呼ばれて初めて本文がロードされる。そのため「実装依頼を受けたら着手前にリスク判定してレビュー工程の重さを決める」のような、どのスキルを起動するか自体を左右するルールをスキル本文に書いても、そのスキルが起動されないケース（軽微な修正依頼を普通の会話で受けたとき）には存在しないのと同じになる。判定ルールが判定対象より後にしかロードされない構造的な穴。

配置の判断基準

• 常時ロードされるコンテキスト（グローバルのメモリ/指示ファイル）に、判定に必要な最小限の要約トリガー（10行前後）＋正本へのポインタを置く。毎ターン確実に効くのはここだけ。
• 判定表の詳細（境界事例・記録様式・例外規定）はスキル側を正本にする。重いケースではそのスキルが必ずロードされるので詳細はそこで効く。二重管理のずれは「常駐側は要約＋ポインタに限定」で防ぐ。
• 軽いケースほどスキルロードなしで完結する設計にする。typo 修正のためにスキル読み込みのオーバーヘッドを払うのは本末転倒。軽量パスの手順は常駐要約だけで実行可能な粒度に収める。
• 判定結果の分類に名前を付けると依頼の語彙になり、ユーザーが名前を明示指定すれば判定自体を省略できる（宣言→介入の余地も生まれる）。

却下した代替案

• 判定用ディスパッチャスキルの新設: 全実装依頼でスキルロードを払うことになり、軽量パスの目的と矛盾する。
• 常駐コンテキストへの全文配置: 常駐コストが高く、スキル側詳細との二重管理ずれが起きる。

検証

スキルを一切呼ばない軽微な依頼を投げ、着手前に判定宣言が出るかで常駐トリガーの効きを確認する。詳細規定が必要な重いケースで正本スキルが参照されるかも別途確認する。