description body coverage resolution priority

body 節と description の被覆ずれは「削る → 移す → 条件追加」の順で解く

Question

skill の body に、その節自身が名指しする発火モーメントがあるのに、ルーティングの唯一の面である description がそのモーメントを持っていない箇所が溜まっていた。この被覆ずれを、どの手段で解くか。

Current resolution

項目ごとに、上から順に適用可能な手段を採る。description への条件追加は最終手段。

1. body 節を削る — その節が load-bearing でない場合
2. 発火モーメントを所有する面へ節を移す — always-on ルール、または既にその瞬間で発火する別 skill の body。listing コストの増加ゼロ
3. description に条件を追加する — 1 / 2 が不可能な場合のみ。選んだ理由を PR 本文に記録する

Provides 句の不正確の是正と、重複条件の削除は、この優先順の対象外として扱ってよい。ただし**「listing コストの減少側だから対象外」という理由づけは誤り**（下記）。

Edges

• depends on skill-trigger-declaration-in-description — 発火条件が description 内に置かれるという前提の上に立つ。when_to_use への分離が将来採用されれば、listing 圧の計算基礎が変わるため本 entry も再評価対象
• depends on li-plus-always-on-footprint-load-bearing — 「安全な圧縮余地は枯渇」という結論が、条件追加を最終手段に置く根拠
• conflicts with（部分的） 同 entry が listing を第 4 の always-on 面として新設した際の暗黙の前提 — 「正確さを上げる修正は圧縮側に働く」。本 entry が実測で反証した（下記）

Background

2026-08-02 の read-only 監査が 44 skill 全文読解で 13 箇所を検出（#1634）。共通形状はひとつ: body に固有の発火条件を散文で抱えた節が追加され、ルーティングする唯一の面である description は前のスコープのまま残された。

素直な解は「description に条件を足す」だが、それは #1542（skill listing が context 予算を超過、9 本が 52 起動で一度も dispatch されていない）の観測と正面から逆を向く。被覆を直す行為そのものが、別の面を壊しうるという構造が問題の核だった。

Constraints

• description は毎起動で全 skill 分が context に載る。条件追加は常時コストの恒久的な増加
• listing 予算を溢れると、使用頻度の低い skill の description から黙って落ちる。ルーティングが静かに壊れる
• 1 skill あたり 1024 字の上限がある。L1 の model-agentic-search は本作業後 1019 字で、残り 5 字

Conclusion

採用 = 優先順の固定。却下 = 「各項目でその都度判断する」形。理由は、判断の余地を残すと検証しやすい軸（被覆の有無）に寄って、常時コストの軸が黙って犠牲になるため。優先順は各項目に対して「まず削れないか」「まず移せないか」を強制的に問わせる。

実測で反証された前提: #1634 は「Provides 句の是正は listing コストの減少側」を前提に優先順の対象外としていた。PR #1643 の実測は touched 13 本の description: 行合計で net +1236 バイト（全 44 本 corpus 比 約 +7%）。減ったのは条件削除 1 件（-118）のみで、Provides 是正は全て増加側だった。正確さを上げると記述は伸びるという非対称を、起票時に見落としていた。

したがって優先順は「コストが減る手段を優先する」ではなく「コストを増やす手段を最後に置く」として読むのが正しい。

検出サイン（この判断が後で疑問視される場合）

• 被覆ずれを見つけて「description に条件を足そう」が最初に浮かんだ時 → 1 と 2 を先に潰したか
• 「Provides を正確にするだけだからコストは増えない」と考えた時 → 実測は逆。増える前提で判断する
• 総括条件（generic umbrella）にぶら下がっている節を見て、個別条件を足そうとした時 → 総括条件で実際に開けなかった実例があるかを先に確認する。無ければ純増でしかない（#1646 の制約欄）

Related

• #1634 / PR #1643 — 非 L1 10 件
• #1641 / PR #1644 — L1 3 件
• #1642 — trigger モードで merge の瞬間にセッションが不在で post-merge 義務が発火しない構造の穴
• #1645 — カテゴリ所有の不在
• #1646 — model-source-check の残余
• #1542 — listing 予算超過の観測