AI スキルの発火は frontmatter description が決める — 用途追加時は分割より先に description へ発火条件を列挙する
設計判断
AIエージェント
AIツール設計
知識
判断
AI エージェントのスキル(Claude Code / Codex の SKILL.md 等)のルーティングは、常時コンテキストに載る frontmatter の description(トリガー一覧)だけで決まり、本文はスキル起動後にしか読まれない。そのため本文が複数の用途をカバーしていても、description に書かれていない用途では発火しない。
症状と原因の切り分け
- 症状: 「この用途はスキルの本文に書いてあるのに、該当する依頼をしてもスキルが呼ばれない」。
- 原因はスキルの中身ではなく description の網羅性。ツールに機能を追加して本文だけ更新すると、この発火漏れが静かに生まれる。本文と description の用途カバレッジを別物としてレビューする。
用途が増えたときの判断基準: description 拡張 vs スキル分割
- まず単一スキルのまま description に全用途と発火条件(ユーザーがどう言ったら使うか)を列挙する。これが最も安く、共有知識(共通の書式・注意点・前提手順)を1か所に保てる。
- 用途別のスキル分割は、共有知識を重複させるか相互参照の多段ホップにするかの二択を生む。分割が割に合うのは、本文が肥大して起動時コンテキストが重くなった場合や、用途ごとに参照資料・許可ツールが大きく異なる場合に限る。
- 分割する場合も正本は一元化し、配布側で複数ファイルに展開する構成にすると同期漏れを防げる。
検証
発火しなかった実際の依頼フレーズ(「スクショ撮って」等)で再度依頼し、スキルが選ばれることを確認する。description は「何ができるか」だけでなく「どんな依頼のときに使うか」の形で書くと一致しやすい。
関連
「スキル description は毎ターン再掲されるため散文ルールより想起されやすい」という完了義務系の知見と機構は同じだが、こちらはスキル自体の用途カバレッジ(発火漏れ)と、その解消手段の選択(拡張 vs 分割)の判断基準。