# Skill Test > スキル定義（SKILL.md）を静的点検・ドライランで検証するスキル。 `--all` で全スキル一括健全性監査モード（ランキング＋修正案ドラフト生成）。 「スキルを点検して」「スキルをテストして」「スキルのバグ確認」「スキル検証」 「全部のスキルを点検して」「一括点検」または /skill-test を呼び出した時にトリガー。 - Skill: `fukukei23/skill-test` (Agent Skill) - Install (CLI): `npx skillmds@latest add fukukei23/skill-test` - Raw SKILL.md: https://api.skillmd.com/api/skills/fukukei23/skill-test/raw - Safety review: PASS (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: fukukei23 (https://skillmd.com/u/fukukei23) - Updated: 2026-08-19 - Page: https://skillmd.com/skills/fukukei23/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 で抽出した全スキル名で一括チェック）: ```bash # 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点 | 精度・可読性（トリガー重複・表記揺れ） | - 各スキルの合計点 = 🔴件数×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: ドライラン 対象スキルを読んだうえで**スキルの種類を判断し**、その種類に応じた正常系・異常系・境界系のシナリオを生成してトレースする。 ### スキルの種類と典型的なシナリオ | 種類 | 代表例 | 正常系で確認すること | 異常系・境界系の例 | |---|---|---|---| | 記録・保存系 | ssot-record | LLM判定 → ファイル書き込み → コミット | LLMが不正な値を返す / 日記末尾に終了時刻あり | | 開発ループ系 | dev-cycle, debug-loop | Issue取得 → 実装 → テスト → 次Issueへ | Issueが0件 / テスト永続失敗 / ループ上限到達 | | UI・ビルド系 | guide-builder, html-guide | Markdown入力 → HTML生成 → push | ビルドエラー / パス解決失敗 | | セッション管理系 | new-session | 文脈収集 → 引き継ぎ生成 → 保存 | コンテキスト空 / 保存先ディレクトリ不在 | | 検索・調査系 | ssot-search | キーワード入力 → 検索 → 結果表示 | 結果0件 / 曖昧マッチ多数 | | 点検・検証系 | skill-test | 対象指定 → 点検 → レポート | 対象スキルが存在しない / 自己参照 | ### シナリオ生成ルール 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 ` でリポジトリを確認してからコミットする（管理下でない場合はスキップ） --- ## 制約・注意事項 - **実際のSSOT書き込みは行わない** — ドライランは「トレース」であり、ファイルへの書き込みは発生しない - **スキル本体のコード実行はしない** — スキルを実際に起動するのではなく、SKILL.mdを「読む」 - **`/debug` との使い分け**: `/debug` はClaude Code組み込みのデバッグログコマンド。`/skill-test` はスキル定義の仕様・設計を静的に点検するスキル。対象が根本的に異なる - **会話コンテキストを必ず参照** — フェーズ1でスキル名が明示されていなくても、直前の会話に「〇〇スキルの点検」などの文脈があれば自動推定して確認を取る - **監査モード（--all）の制約**: - ドライラン（フェーズ3相当）は監査では実施しない（速さ優先）。深掘りが必要なスキルは個別に `/skill-test <スキル名>` で再点検 - 機械的チェック（grep）は補助。観点1（記述整合性）等は必ず人間がSKILL.mdを読んで判断する - 🔴判定は慎重に。誤発火・未発火・セキュリティ等、動作に直接影響するもののみ