Skill Doctor
あらゆるSKILL.mdを診断し改善します。マニュアルではなくコンパス — 具体的な基準は references/ にあり、オンデマンドで読み込まれます。
トリガー後の診断フロー（各ステップは可視出力を生成する必要があります）
可視出力がないステップは暗黙にスキップされます（Seleznov experiment, 2026）。ステップごとに1行の確認行を出力してください。 自己レビューフラグ: このセッションでターゲットのSKILL.mdをすでに編集/書き込みしている場合、すべてのdoctor出力行に
[self-review]をプレフィックスとして付け、ステップ3の最後に「結論は自己評価に基づきます。新しいサブエージェントで再レビューすることを推奨します」という行を1行追加してください。
ステップ1: ターゲットSKILL.mdを読み、診断開始を宣言する
編集中のSKILL.mdの全文を読み、python3 <this-skill-dir>/scripts/check_listing_budget.py "<project_root>" を実行し（パスを引用符で囲む — スペースが一般的なため）、次の2行を出力します。
[skill-doctor] Auditing: <path> body=<N> lines description=<M> chars
[skill-doctor] Budget (<platform>): <K> skills, <T> chars vs ≈<B> → <fits | OVERFLOW ×N.N>
プラットフォームを自動検出します（CC / Codex / Hermes / OpenClaw）。終了コード: 0 = 収まる; 1 = オーバーフロー; 2 = 利用不可（プラットフォームなし / コンテキスト不明 → ユーザーにプラットフォーム＋ウィンドウを尋ねる）。オーバーフローは集団レベルのNOTICEであり、監査対象スキルに対する所見ではありません: ユーザーが数値を認識できるように出力しますが、予算の都合でこのスキルの説明文を短くしないでください — スリミングはグローバルパスであり、単一スキルの修正ではありません。
ステップ2: 次元に基づいて判定する
参照インデックス（次元セクション）から読み込む次元を選択します — when-to-read が発火するエントリのみを読みます。 読み込み後、1行出力します。
[skill-doctor] Loaded: <list>; Skipped: <list with one-word reason>
ステップ2.5: ドライランのウォークスルー（本文にワークフローが含まれる場合のみ）
references/effect-dry-run.md に従い、最も典型的なプロンプト1つを取り、本文のステップをウォークスルーし、入力/指示/出力が接続されているか確認します。
リンク切れや曖昧さがある場合 → P0（エフェクト問題）としてマークし、ステップ3の❌セクションに配置します。
1行出力します。
[skill-doctor] Dry-run prompt: "<prompt>" broken links=<N>
本文にワークフローがない場合（純粋なルール/参照型スキル）、次の行を出力します。
[skill-doctor] Dry-run: skipped (no workflow)
ステップ2.6: ライブインジェクションチェック（ターゲットスキルが現在のセッションのスコープ内にある場合のみ）
ターゲットが現在のセッションの利用可能スキルリストに説明文付きで（名前のみではなく）表示されているかを確認します。3つのケース（injected / name-only budget-drop / out-of-scope skip）および集団通知ルールについては references/live-injection-check.md を参照してください。1行出力します。
[skill-doctor] Live-injection: <injected | DROPPED (name-only) | skipped (<reason>)>
ステップ3: 診断レポートを出力する
以下の形式に厳密に従い、会話に出力します。
[skill-doctor] Diagnosis
❌ Must fix (sorted P0→P3, definitions in references/priority-tiers.md)
[P0 effect break] <issue>: <why> → <fix>
[P1 structure] <issue>: <why> → <fix>
[P2 specificity] <issue>: <why> → <fix>
[P3 affects execution] <issue>: <why> → <fix>
⚠️ Suggested improvements (including purely cosmetic / verbose P3)
- <issue>: <why> → <fix>
✅ Checks passed
- <list>
P3配置ルール: 「修正しない場合、次にこのスキルを実行するLLMが誤った動作をするか？」と自問してください — はい → ❌; 単に醜い/冗長 → ⚠️。references/priority-tiers.md を参照してください。
各問題は具体的な行番号またはフィールドを示す必要があります — 曖昧さは禁止です。同じ種類の違反が複数箇所にある場合は、個別に列挙してください — 例: 3つのサブディレクトリに誤って分類されたコンテンツは、1つの統合エントリではなく3つの問題として扱います。
該当する場合は障害モードに名前を付けます（references/predictability-glossary.md 参照）: 所見に [no-op] / [sediment] / [premature-completion] / [weak-leading-word] / [duplication] / [sprawl] のプレフィックスを付けます。この名前は種類を示し、P階層は依然として深刻度を示します — 直交しているため、プレフィックスが階層に取って代わることはありません。
ステップ4: ユーザー確認後に編集を適用する
確認なしに編集してはいけません。ユーザーが「修正して」と言うのを待ってから行動します。
行動する前に、サイズゲートと事前削除チェックを適用し、その後ループをクローズします — 完全な手順は references/apply-safety.md にあります。
修正後、1行出力します。
[skill-doctor] Applied <N> fixes to <path> body: <old>→<new> lines (<+X%>)
ハードルールのクイックリファレンス
定量化されたハードルール（違反はエラーであり、提案ではありません）は references/hard-rules.md にあります — 監査のたびに参照してください。
例外フォールバック
パスが見つからない、YAMLが解析できない、バンドルスクリプト（scripts/check_listing_budget.py + scripts/detect_platform.py / scripts/check_routes.py / scripts/eval_retrieval.py / scripts/check_desc_slim.py）がないか終了コード2で終了した場合 — references/exception-fallback.md に従って処理します。例外を最初にユーザーに通知し、決して黙ってスキップしないでください。
出力と言語
レポートの散文は references/output-style.md に従います（明確、ターミナルセーフ、結論ファースト）。本体/参照はデフォルトで英語です; 正当化されていない非英語には ⚠️ フラグを立てます — ポリシーと2つの正当な例外は references/language-policy.md にあります。
このスキルの対象外
- 実際の機能が正しいかどうか（それはロジックバグであり、スキル形式の問題ではありません）
- プロジェクト固有の規約（これらはスキルではなくCLAUDE.mdに記述します）
- 一度限りの修正スクリプト（一度実行したら破棄されるものはスキルにすべきではありません）
このスキルが存在する理由
LLMがなぜSKILL.mdをマニュアルとして誤って記述するのか、そしてこのスキルが機械的チェックと判断をどのように分離するか: references/rationale.md を参照してください。