Skill Test

skill-test スキル

概要

スキル定義ファイル（SKILL.md）を対象に以下を実行する:

1. 特定 — どのスキルを点検するかを確定
2. 静的点検 — SKILL.md全文を読んでフェーズ設計・パス・条件分岐・記述の矛盾を検査
3. ドライラン — 対象スキルの種類に応じたシナリオで各フェーズをトレース
4. レポート — バグ・矛盾・懸念を重大度別に列挙
5. 修正 — ユーザー承認を得て修正を適用

フェーズ0: 監査モード分岐

起動時に以下のいずれかが成立する場合、監査モード（全スキル一括健全性点検） に分岐する。それ以外は従来の1スキル点検フロー（フェーズ1〜）へ進む。

• 引数指定: --all（例: /skill-test --all）
• キーワード: 「全部」「すべて」「全スキル」「一括」「一括点検」「全点検」等の表現

（※ 監査モード = 起動状態、監査フロー = その時に実行する監査Step 1〜5の手順）

監査モードの処理は「監査フロー（監査Step 1〜5）」セクションに従う。 以降のフェーズ1〜5は監査モードでは使用しない。

監査モードに入らない場合は、このフェーズ0をスキップしてフェーズ1へ進む。

監査フロー（監査モード専用）

監査Step 1: スキャン

Run: ls -d ~/projects/claude-config/skills/*/ 取得したディレクトリ一覧から ディレクトリ型スキルのみ を監査対象とする。.md 単体ファイル（delegate-to-minimax.md 等）は除外。

対象数をユーザーに提示（例: 「27スキルを点検します」）。 対象が0件の場合は「監査対象スキルなし」と表示して終了する。

監査Step 2: 横断点検（6観点 × 全スキル）

各スキルの SKILL.md を読み、以下6観点でチェックする。機械的チェック（grep）を併用して高速化する。

以下の grep は <対象> を各スキルのディレクトリ名に置換して、全スキル分繰り返し実行する。

観点1: 記述整合性

• description: のトリガー文言と本文の実装が一致しているか
• 書かれている機能が実際にSKILL.md内で実装されているか

観点2: トリガー競合（誤発火リスク）

• 他スキルと同じトリガーワードが無いか（特に prefix 関係・テーマ修飾語の重複等）
• 汎用語（「提案して」「記録して」等）の複数スキルでの重複

観点3: 汎用性（LLM名ハードコード）

Run: grep -rn "GLM\|MiniMax\|Sonnet" ~/projects/claude-config/skills/<対象>/SKILL.md

• LLM名が固定記述（「GLMで実行」等）になっておらず、「LLM」「AI」等の汎用表現か
• ※バッジ表示ルール（🟡[GLM]等）はハードコードとして扱わない（仕様）

観点4: パス環境依存

Run: grep -n "~/\|\$HOME\|//wsl.localhost\|/home/yn4416\|/c/Users" ~/projects/claude-config/skills/<対象>/SKILL.md

• WSL CLI用（/home/yn4416/）とWindows用（//wsl.localhost/Ubuntu/・/c/Users/）の使い分けが明記されているか
• ~/・$HOME が環境で解決されるか、絶対パスが必要な箇所に相対パスが無いか

観点5: セキュリティ

Run: grep -ni "api.key\|secret\|token\|password" ~/projects/claude-config/skills/<対象>/SKILL.md

• APIキー値の直書きが無いか（キー名はOK・値はNG）
• 外部公開リポジトリへの機密情報書き込みが無いか

観点6: カタログ掲載一致性（※SKILL.md本文ではなく外部カタログをチェック）

各スキルが、利用者が検索する一覧表カタログ（全スキル掲載が期待されるページ）に掲載されているか。未掲載のまま放置されると「スキルを作ったのに一覧から見つからない」陳腐化（過去 demo-site-sales・resume-session・sentaku 等の漏れ事例）を検出する。

Run（監査Step 1 で抽出した全スキル名で一括チェック）:

# SKILL_CATALOG.md（一覧表マスター・全スキル掲載が期待される）に掲載されているか
for s in $(ls -d ~/.claude/skills/*/ | xargs -n1 basename); do
  hit=$(grep -c "\`${s}\`" ~/projects/obsidian-ssot/00_SYSTEM/Claude-Codeガイド/SKILL_CATALOG.md)
  [ "$hit" = "0" ] && echo "${s}: 一覧表に未掲載"
done

• 判定: 一覧表（SKILL_CATALOG.md）=0 のスキルを 🟡中程度 で検出
• 詳細版 03_スキルシステム.md は自動チェック対象外: 同ページは「主要スキルの詳細説明」のみを掲載する設計（全スキル掲載を意図しない）。何を「主要」とするかは人間判断のため、本観点では一覧表のみ検証する
• 公開版（claude-code-guide/source/SKILL_CATALOG.md）への伝播 は update-guide の担当。本観点はSSOTマスター（00_SYSTEM/Claude-Codeガイド/SKILL_CATALOG.md）の掲載のみ検証する
• 除外規準: 内部用・deprecated のみ人間判断で除外可

監査Step 3: ランキング化

検出した問題を重大度で分類し、重み付け集計 でスキルごとの健全性スコアを算出する。

• 各スキルの合計点 = 🔴件数×3 + 🟡件数×2 + 🔵件数×1
• 合計点が高いほど健全性が低い（=より改良が必要）
• 合計点の降順でランキング

監査Step 4: 出力（3層）

層1: 健全性ランキング表

| 順位 | スキル | 🔴 | 🟡 | 🔵 | 合計点 |
|---|---|---|---|---|---|
| 1 | <スキル名> | n | n | n | n |
| ... | ... | - | - | - | - |

合計点降順。上位ほど改良優先度が高い。

層2: 弱点スキル詳細レポート

合計点 > 0 のスキルのみ、以下のフォーマットで 🔴/🟡/🔵 別に列挙:

## <スキル名>（合計点: n）

### 🔴 重大
① <問題>
  - 現象: ...
  - 修正案: ...

層3: 修正案ドラフト

各弱点に what / why / fix案 の3点セットを付与。writing-plans に直接入力できる形式:

### 修正案: <スキル名>①
- what: 何をどう変えるか（1文）
- why: なぜ（影響・リスク）
- fix案: 具体的な修正内容（ファイル:行・変更後の記述）

監査Step 5: 保存・バックログ取り込み

監査結果を以下に保存する:

1. 監査レポート: obsidian-ssot/01_DECISIONS/claude-code/YYYY-MM-DD_skill健全性監査.md（実施日）
   • 層1（ランキング）・層2（詳細）・層3（修正案ドラフト）を全て格納
2. バックログ取り込み: obsidian-ssot/00_SYSTEM/バックログ.md に修正案を P0/P1/P2 エントリとして追記
   • P0: 🔴 重大案件
   • P1: 🟡 中程度
   • P2: 🔵 軽微
3. 日記更新: obsidian-ssot/10_DAILY/YYYY-MM-DD.md にサマリー＋監査レポートへのリンク

ドライランは行わない（ファイル書き込みは実際に発生する）。保存前にユーザーに「Nスキル分のレポートを保存しますか？」と確認する。

フェーズ1: スキル特定

以下の優先順で対象スキルを特定する:

1. 会話コンテキスト優先 — 直前の会話で話題になっているスキルがあれば自動採用（確認不要）
2. 引数指定 — /skill-test ssot-record のようにスキル名が渡された場合はそれを使用
3. 一覧から選択 — 上記いずれもなければ ~/.claude/skills/（WSL: /home/yn4416/.claude/skills/、Windows: C:\Users\yn441\.claude\skills\）配下のスキル一覧を表示してユーザーに選ばせる

• ユーザーが「やめる」「キャンセル」などを回答した場合はスキルを中断して終了する
• 特定後、SKILL.mdのフルパスを確定して次フェーズへ

フェーズ2: 静的点検

SKILL.mdを全文読み、以下の観点でチェックする。

2-1. フェーズ設計の整合性

• フェーズ間の依存・順序に矛盾がないか
• 前フェーズの出力が次フェーズの入力として正しく引き継がれているか
• 「後で」「必要に応じて」など曖昧なトリガーで重要ステップが省略される恐れがないか

2-2. 条件分岐の網羅性

• LLM/AIの返答が想定外の値（存在しないフォルダ名・空文字・null等）だった場合の処理があるか
• yes/no 以外の回答（「後で」「やめる」等）へのハンドリングがあるか
• エラー時・タイムアウト時のフォールバックが定義されているか

2-3. パス・コマンドの環境依存

• ~/ や $HOME がWSL/Windows両環境で正しく解決されるか
• 絶対パスが必要な箇所に相対パスが使われていないか
• WSL CLI用（/home/yn4416/...）とWindows用（//wsl.localhost/Ubuntu/...）の使い分けが適切か

2-4. 記述の整合性

• description のトリガー文言と本文の実装が一致しているか
• LLMを呼ぶ箇所が「GLM」固定になっておらず汎用的（「LLM」「AI」等）か
• 廃止・変更されたファイルパスや仕様が残っていないか

2-5. セキュリティ

• APIキー値をファイルに書き込む処理がないか
• 外部公開リポジトリへの機密情報の書き込みがないか

フェーズ3: ドライラン

対象スキルを読んだうえでスキルの種類を判断し、その種類に応じた正常系・異常系・境界系のシナリオを生成してトレースする。

スキルの種類と典型的なシナリオ

シナリオ生成ルール

1. SKILL.mdのフェーズ構成・トリガー・LLM利用の有無を確認してスキルの種類を特定する
2. 上の表を参考に、対象スキル固有の正常系・異常系・境界系を3パターン生成する
3. 各シナリオで「このフェーズでこの入力を受け取ったとき、スキルの記述通りに動くか」をトレースし、動かない・曖昧なケースをバグとして記録する

ドライランは問題0件でも必ず実施する — 静的点検では気づけない実行時の抜けを発見するため

フェーズ4: レポート出力

発見した問題を以下フォーマットで列挙する:

## 点検レポート: <スキル名>

### 🔴 重大（動作に影響する）
① <問題タイトル>
  - 現象: ...
  - 修正案: ...

### 🟡 中程度（誤動作につながる可能性）
② ...

### 🔵 軽微（精度・可読性に影響）
③ ...

### ✅ 問題なし
- ...

問題がゼロの場合も「点検完了 — 問題なし」と表示してフェーズ5へ進む。

フェーズ5: 修正適用

レポートを提示した後、以下を確認する:

上記 N 件を修正しますか？
  [A] 全件まとめて修正
  [S] 重大（🔴）のみ修正
  [R] 個別に選択
  [N] 修正しない（レポートのみ）

• [A]/[S]/[R]/[N] 以外の回答（「後で」「②だけ」等）の場合は「[A]/[S]/[R]/[N] でお答えください」と再確認する
• ユーザーの選択に従い SKILL.md を編集する

修正後:

• 変更内容を diff 形式で表示
• git commit する場合は git -C <SKILL.mdのあるディレクトリ> でリポジトリを確認してからコミットする（管理下でない場合はスキップ）

制約・注意事項

• 実際のSSOT書き込みは行わない — ドライランは「トレース」であり、ファイルへの書き込みは発生しない
• スキル本体のコード実行はしない — スキルを実際に起動するのではなく、SKILL.mdを「読む」
• /debug との使い分け: /debug はClaude Code組み込みのデバッグログコマンド。/skill-test はスキル定義の仕様・設計を静的に点検するスキル。対象が根本的に異なる
• 会話コンテキストを必ず参照 — フェーズ1でスキル名が明示されていなくても、直前の会話に「〇〇スキルの点検」などの文脈があれば自動推定して確認を取る
• 監査モード（--all）の制約:
  • ドライラン（フェーズ3相当）は監査では実施しない（速さ優先）。深掘りが必要なスキルは個別に /skill-test <スキル名> で再点検
  • 機械的チェック（grep）は補助。観点1（記述整合性）等は必ず人間がSKILL.mdを読んで判断する
  • 🔴判定は慎重に。誤発火・未発火・セキュリティ等、動作に直接影響するもののみ