skill-test

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは .claude/docs/automation-modes.md に従います （collaborative は常に質問 · guided は大きな変更のみ · autonomous はログを記録して続行； automation_always_ask のカテゴリでは常に確認を求めます）。

スキルテスト

スキル（.claude/skills/*/SKILL.md）とエージェント（.claude/agents/*.md） の構造上の準拠と動作の正しさを検証します。外部依存関係はなく、 既存のスキル／フック／テンプレートのアーキテクチャ内だけで実行されます。

4 つのモード：

モード	コマンド	目的	トークンコスト
static	/skill-test static [name|all]	構造リンター — スキルごとに 7 項目の準拠チェックを行い、エージェント、委任、互換性に関する所見も確認します	低（スキルあたり約 1k）
spec	/skill-test spec [name]	動作検証 — スキルまたはエージェントのテスト仕様にあるアサーションを評価します	中（各約 5k）
category	/skill-test category [name|all]	カテゴリ別ルーブリック — スキルまたはエージェントをカテゴリ固有の指標に照らして確認します	低（各約 2k）
audit	/skill-test audit	カバレッジレポート — スキル、エージェント仕様、最終テスト日を表示します	低（合計約 3k）

合格が証明すること。 どのモードもファイルを読み取りますが、スキルを実行することはありません。static： ファイルがスキルに必要な構造を備えていることを示すものであり、正しく動作することを示すものではありません。spec：指示を 詳しく読み、各ケースが網羅されていることを評価しますが、実行時に Claude がそれに従うことを示すものではありません。 category：スキルが記述どおりに、そのカテゴリのルーブリックを満たしていることを示します。audit： 仕様があるスキルとエージェント、およびそれぞれの最終確認日を示します。スキルの実際の動作を確認できるのは、実行時だけです。 Anthropic の Agent Skills ベストプラクティス「Build evaluations first」に従い、プロジェクトの使い捨てコピーで、 使用する各モデルを対象に、スキルあり／なしの両方で実際のリクエストを実行してください。

---

フェーズ 1：引数の解析

最初の引数からモードを判定します。

• static [name] → 1 つのスキルに対して 7 つの構造チェックを実行するか、1 つのエージェントに対して所見を確認します
• static all → すべてのスキル（Glob .claude/skills/*/SKILL.md）に対して 7 つの構造チェックを実行し、すべてのエージェントについても所見を確認します
• spec [name] → スキルまたはエージェントとそのテスト仕様を読み、アサーションを評価します
• category [name] → studio-tests/quality-rubric.md のカテゴリ別ルーブリックを実行します
• category all → カタログに category: があるすべてのスキルとエージェントに対して、カテゴリ別ルーブリックを実行します
• audit（または引数なし）→ カタログを読み、すべてのスキルとエージェントを一覧表示して、カバレッジを示します

認識できない引数の場合は、使い方を出力して停止します。

旧仕様フォルダー。 CCGS Skill Testing Framework/catalog.yaml を Glob します。 見つかった場合は、最初に次のように伝えます：「CCGS Skill Testing Framework/ は 1.2.0 で studio-tests/ に名前が変更されました。このスキルは studio-tests/ のみを読み取ります。 そこに作成した仕様を移動してください。方法は UPGRADING.md（v1.1.3 → v1.2.0、studio-tests/）に記載されています。」 その後、studio-tests/ を使って処理を続けます。

spec または category の前に名前を解決します。 studio-tests/catalog.yaml で名前を検索します。 skills: の下にある項目はスキルです（.claude/skills/[name]/SKILL.md）。agents: の下にある項目はエージェントです （.claude/agents/[name].md）。カタログに項目がない場合は、該当する 2 つのファイルのうち存在する方を使います。 どちらも存在しない場合に限り、「'[name]' は .claude/skills/ のスキルでも .claude/agents/ のエージェントでもありません。」と報告して停止します。 通常の単語と同じ名前であっても、名前として扱います：/skill-test spec help は /help スキルをテストし、このスキルの使い方を尋ねるリクエストとしては扱いません。

7 つのチェックは SKILL.md の構造を検査するため、スキルのみが対象です。エージェント名が指定された場合、 static は以下の所見のみを確認します。エージェントファイルには検査対象となるフェーズや判定キーワードがありません。 エージェントを見つからないものとして報告してはいけません。

---

フェーズ 2A：静的モード — 構造リンター

テスト対象の各スキルについて、SKILL.md と references/ フォルダー内のすべてのファイルを 最後まで読み、スキル全体を1つの単位として7つのチェックをすべて実行します。最も長いスキルでは、 各フェーズが references/ に分割されています。フロントマターチェック（1、6、7）では SKILL.md を読みます。

チェック 1 — 必須フロントマターフィールド

ファイルの YAML フロントマターブロックに、以下のすべてが含まれている必要があります。

• name:
• description:
• argument-hint:
• user-invocable:
• allowed-tools:

FAIL：いずれかが欠けている場合。フロントマターを解析できないファイルもチェック 1 で失敗します。形式不正な YAML は、このチェックで検出する構造上の欠陥であり、評価不能なファイルではありません。以下のスキルごとの結果ルールを参照してください。

チェック 2 — 複数フェーズ

スキルには、番号付きのフェーズ見出しが2つ以上必要です。次のようなパターンを探します。

• ## Phase N または ## Phase N:
• ## N.（番号付きのトップレベルセクション）
• フェーズが明示的に番号付けされていない場合は、異なる ## 見出しが2つ以上

FAIL：フェーズに相当する見出しが2つ未満の場合。

チェック 3 — 判定キーワード

スキルは明確な結果を示す必要があります。次のいずれかを受け入れます。

• ゲート／レビュー判定 — PASS、FAIL、CONCERNS、APPROVED、 BLOCKED、COMPLETE、READY、COMPLIANT、NON-COMPLIANT
• 続行／中止の判定 — PROCEED、PIVOT、KILL、GO、NO-GO
• 重大度の段階 — CRITICAL、HIGH、MEDIUM、LOW。監査スキルでは 実行全体に対する単一の判定ではなく、重大度で指摘事項をランク付けします。

FAIL：いずれも含まれておらず、かつスキルが評価を行う場合。説明または本文で、レビュー、監査、チェック、ゲート、準備状況の判定を行うと約束している場合が該当します。

WARN（FAILにはしない）：いずれも含まれておらず、スキルの出力が判定ではなく成果物や値である場合。基準となる例は /settings です。設定を出力して書き込み、判定を下す必要はありません。このチェックを満たすために判定を作り出してはいけません。

より限定的なリスト、つまりゲート判定のみを許可し、それ以外はすべて厳格に FAIL とする方法では、本来は問題のない理由でスキルが誤って失敗になります。/prototype と /vertical-slice は、それぞれの説明で PROCEED／PIVOT／KILL を掲げており、/adopt と /security-audit は重大度でランク付けし、/settings は設計上判定を行いません。正当なパターンを誤って失敗とするリンターは、信頼されなくなります。

チェック 4 — 協調プロトコルの文言

スキルには、書き込み前に確認を求める文言が必要です。次を探します。

• "May I write"（標準形式）
• ファイル書き込みの指示付近にある "before writing" または "approval"
• 近接している "ask" と "write"（同じセクション内）

WARN：見つからない場合（一部の読み取り専用スキルでは、正当に省略されます）。 FAIL：allowed-tools に Write または Edit が含まれているにもかかわらず、書き込み前の確認を求める文言が見つからない場合。

チェック 5 — 次のステップへの引き継ぎ

スキルの末尾には、推奨される次のアクションまたはフォローアップの手順が必要です。次を探します。

• 別のスキルに言及する最後のセクション（例：/story-done、/gate-check）
• 「Recommended next」または「next step」という表現
• 「Follow-Up」または「After this」というセクション

WARN：見つからない場合。

チェック 6 — フォークコンテキストの複雑さ

フロントマターに context: fork が含まれる場合、スキルにはフェーズ見出し（## レベル、または番号付きの Phase N 見出し）が5つ以上必要です。フォークコンテキストは、複雑で複数フェーズからなるスキル向けです。シンプルなスキルでは使用しないでください。

WARN：context: fork が設定されているものの、フェーズが5つ未満の場合。

チェック 7 — 引数ヒントの妥当性

argument-hint は空であってはなりません。スキル本文に複数のモード（例：「Mode A | Mode B」）が記載されている場合、ヒントにもそれらが反映されている必要があります。最初のフェーズにある「Parse Arguments」セクションとヒントを照合します。

WARN：ヒントが "" の場合、または記載されたモードがヒントと一致しない場合。

エージェントと委任に関する所見（採点対象外）

スキルの場合は bash .claude/scripts/agent-check.sh --skill [name]、エージェントの場合は bash .claude/scripts/agent-check.sh --agent [name] を実行します。または、static all の場合は bash .claude/scripts/agent-check.sh を一度実行します。所見を出力しますが、判定は行わず、 ここに記載された内容によってスキルの判定が変わることもありません。各項目を判断し、 Observations: の下に報告してください。

• DELEGATION: エージェントに作業を委ねるスキルの一部分です。そこを読み、 指示に目的、出力形式、ツールと情報源、境界が示されているか、またエージェントに 数回のツール呼び出しだけで済む作業を割り当てているか、それともスキル自身の作業の 再確認を割り当てているかを述べてください。markers: は確認すべき箇所を示す語数であり、 評価ではありません。
• AGENT: 設定されているモデル、作業量、ターン制限、および説明の横にあるツールを 確認してください。説明にある作業で不要なツールがあれば、その名前を挙げてください。
• NOTE: 解析できないフロントマター、asks-user（エージェントには質問ツールがないため、 質問は報告の最後に記載します）、無視される設定、または記載された内容以上の動作をする設定 （agent-type-list、preload-off、disallowed-specifier、memory-grants）です。
• OVERLAP: 特徴的な語句が重複する2つの説明です。それぞれの説明でエージェントが 明確に特定されるか、どのような依頼が誤ったエージェントに割り当てられるかを述べてください。

スクリプトを実行できない場合は、Observations: not run (<reason>) と記載してください。 このセクションを省略してはいけません。セクションがない場合、問題がなかったものと 同じように読み取られます。

互換性に関する所見（採点対象外）

スキルの場合は bash .claude/scripts/compat-inventory.sh --skill [name]、エージェントの場合は bash .claude/scripts/compat-inventory.sh --agent [name] を実行します。または、static all の場合は bash .claude/scripts/compat-inventory.sh を一度実行します。各 FOUND: 行は、そのファイルが Claude Code でのみ提供される機能に依存している箇所と、その機能を示します。機能は、 questions、subagents、skill-loading、shell-lines、arguments、frontmatter、instructions、hooks、 settings、tools のいずれかです。Claude Code はこれらすべてを実行するため、どれも欠陥ではなく、 判定にも影響しません。Compatibility: の下に、機能ごとに構文と行番号を1行で報告してください。 static all の場合は、機能ごとの COUNT: 合計を記載してください。NOT FOUND: 行は、 名前に一致するファイルがなかったことを意味します。その旨を記載してください。スクリプトを 実行できない場合は、Compatibility: not run (<reason>) と記載してください。

---

静的モードの出力形式

単一スキルの場合：

=== Skill Static Check: /[name] ===

Check 1 — Frontmatter Fields:    PASS
Check 2 — Multiple Phases:       PASS (7 phases found)
Check 3 — Verdict Keywords:      PASS (PASS, FAIL, CONCERNS)
Check 4 — Collaborative Protocol: PASS ("May I write" found)
Check 5 — Next-Step Handoff:     WARN (no follow-up section found)
Check 6 — Fork Context Complexity: PASS (8 phases, context: fork set)
Check 7 — Argument Hint:         PASS

Observations (not scored):
  Delegation, "Phase 3: Implementation" (line 202): ux-designer, ui-programmer.
    The brief names the output file and limits but no sources to read.

Compatibility (not scored):
  questions: AskUserQuestion (lines 13, 88) · shell-lines: shell-line (line 10)
  frontmatter: allowed-tools, argument-hint, model, user-invocable (lines 4-7)

Verdict: WARNINGS (1 warning, 0 failures)
Recommended: Add a "Follow-Up Actions" section at the end of the skill.

単一エージェントの場合、判定はなく、所見のみです：

=== Agent Static Check: qa-lead ===

Model: inherit · Effort: unset · Turn limit: 20
Tools: Read, Glob, Grep, Write, Edit, Bash. Fits the job (it writes test plans).
Observations (not scored):
  asks-user (lines 31, 52): tells the agent to get approval before writing.
  overlap with qa-tester (creation, regression, test): each still singled out.
Compatibility (not scored):
  frontmatter: tools, tools-string, model, maxTurns (lines 4-6)

WARN または FAIL の行には原因を括弧内に記載します。COMPLIANT 以外の判定には、 修正内容を示す Recommended: 行を必ず付けてください。

単一スキルの Verdict: は、static all の Result 列と同じ4つの値のいずれかです： COMPLIANT（警告も失敗もなし）、WARNINGS（警告はあるが失敗はなし）、 NON-COMPLIANT（FAIL がある）、NOT ASSESSED（ファイルを読み取れないか解析できない、 またはチェックを実行できない — 理由を記載）。

static all の場合は、サマリーテーブルを作成してから、非準拠のスキルを列挙してください：

=== Skill Static Check: All 74 Skills ===

Skill                  | Result       | Issues
-----------------------|--------------|-------
gate-check             | COMPLIANT    |
design-review          | COMPLIANT    |
story-readiness        | WARNINGS     | Check 5: no handoff
...

Summary: 48 COMPLIANT, 3 WARNINGS, 1 NON-COMPLIANT, 1 NOT ASSESSED
Aggregate Verdict: N WARNINGS / N FAILURES / N NOT ASSESSED

Agents (observations, not scored): 49 read
  asks-user: N agents · agent-type-list: N · preload-off: N · frontmatter: N
  Overlap pairs: [each pair, with whether both are still singled out]
  Delegation blocks: N in N skills; [the ones whose brief lacks a part]

Compatibility (not scored): N FOUND lines in N of N files read
  [feature]: [construct] N files, N hits; ...   (one line per feature)

NOT ASSESSED はここではスキルごとの結果であり、全体の集計行だけを指すものではありません。 ファイルが見つからない、権限がないなどの理由で読み取れず、チェックを開始できないスキルは、 理由を添えて NOT ASSESSED として報告してください。テーブルから省いたり、COMPLIANT として 数えたりしてはいけません。優先順位は COMPLIANT より上、WARNINGS および NON-COMPLIANT より下 です。ファイルを読み取れたものの、フロントマターを解析できない場合は別のケースです。 上記のとおり、チェック1が失敗するため、NOT ASSESSED ではなく NON-COMPLIANT として 報告してください。これはリンターがファイルにアクセスできない問題ではなく、スキルの欠陥です。

分母も明記してください。 ヘッダーの All 74 Skills は、存在するスキルの数ではなく、 実際に調査した数でなければなりません。異なる場合は [N] of [M] skills checked と報告してください。 タイトルの数と集計の合計が一致しないサマリーは、このスキルがほかのスキルで見つけるべき 不具合です。

静的モードではファイルを書き込みません。

---

Phase 2B: 仕様モード — 動作検証

ステップ 1 — ファイルを特定する

フェーズ 1 で解決したスキルまたはエージェントのファイルを使用します。 studio-tests/catalog.yaml で仕様のパスを調べます。一致する skills: または agents: エントリの spec: フィールドを使用してください。

いずれかが見つからない場合：

• スキルまたはエージェントが見つからない場合：フェーズ 1 のメッセージ。
• カタログに仕様のパスがない場合：「No spec path set for '[name]' in catalog.yaml.」
• 指定されたパスに仕様ファイルが見つからない場合：「Spec file missing at [path]. Run /skill-test audit to see coverage gaps.」

ステップ 2 — 両方のファイルを読む

スキルの場合は SKILL.md と references/ フォルダー内のすべてのファイルを、エージェントの場合はエージェントファイルを、そしてテスト仕様ファイルを、すべて最後まで読みます。

ステップ 3 — アサーションを評価する

実行中のモデルが確認できる内容に基づいて評価します。 スキルはセッション内で実行され、起動されたエージェントは独自のコンテキスト内で実行されます。どちらにも、プロジェクトの CLAUDE.md と、@path 行でインポートするすべてのファイルが読み込まれます（起動されたエージェントは coordination-rules.md を読まずに一言一句そのまま引用します）。これらのファイルも読んでください。そこに記載されたルールは、すべてのスキルとエージェントに適用されます。引用元のファイルを明記してください。スキルまたはエージェント自身のファイルがそれらと矛盾する場合は、より具体的な指示である自身のファイルを優先します。

エージェントの場合、仕様の各セクションはエージェントファイルと、そのフロントマターの skills: に記載されたすべてのスキル（Claude Code がエージェントの起動時に読み込みます）に照らして評価します。

• 静的アサーション — 各項目をエージェントのフロントマターと本文に照らして確認します。リテラル値（model: のエイリアス、フロントマターのキー、ツール名など）を指定するアサーションは、ファイルとの完全一致が必要です。model: inherit は「Model tier is sonnet」を満たしません。また、近似一致は一部一致ではなく、必ず FAIL です。
• テストケース — スキルのテストケースと同じ方法で、各ケースの期待される動作をエージェントの記述された指示に照らして評価します。ゲート ID（LP-FEASIBILITY、CD-PILLARS、…）を指定するケースは、そのゲートの実行を指します。起動するスキルは、エージェントにまず .claude/docs/director-gates/[gate-id].md を読ませるため、そのファイルの Prompt と Verdicts がそのケースにおけるエージェントの指示になります。そのファイルも読んでください。
• リダイレクトおよびエスカレーションのケース — エージェントに別の役割が担当する作業が依頼された場合、またはエージェントだけでは解決できない競合がある場合です。読み込まれた coordination-rules.md がその手順を規定しているときにケースを満たします。つまり、ルール 2（担当領域外で拘束力のある決定をしない）、ルール 3（競合を共通の親にエスカレーションする）、またはルール 5（委任なしに担当ディレクトリ外のファイルを扱わない）のいずれかに加え、エージェント自身のファイルの協力者、委任、エスカレーション、または「してはならない」リストに担当する役割が明記されている必要があります。両方を引用してください。エージェント自身の言葉でリダイレクトを言い直すことは求めないでください。エージェント自身のファイルがその作業を自分の担当だと主張している場合、または読み込まれたファイルのどれにも担当者が記載されていない場合は、FAIL です。
• プロトコル準拠 — 以下の 4 つのスキルチェックの代わりに、仕様独自の ## Protocol Compliance リストを使用します。

スキルの場合、仕様の静的アサーションを、同じ方法でスキルのフロントマターと本文（SKILL.md および references/ 内のファイル）に照らして確認します。リテラル値は完全一致が必要です。/skill-test static が実行するのは、固定の 7 項目のチェックだけです。したがって、仕様独自の静的アサーション（判定キーワード、フェーズ、「指定されたファイルの前に『May I write』と尋ねる」など）は、ここで評価するか、評価されないままになります。

このステップの残りの部分は、スキルとエージェントの両方に適用されます。

仕様の各テストケースについて：

1. フィクスチャの説明を読みます（プロジェクトファイルの想定状態）。
2. 期待される動作のステップを読みます。
3. アサーションのチェックボックスをそれぞれ確認します。

フィクスチャがないケースでは、入力をフィクスチャとして読みます。アサーションのリストがないケースでは、期待される動作の各項目をアサーションとして扱います。多くのエージェント仕様はこの形式で記述されており、独立したチェックリストがないというだけで、ケースの判定を未定義のままにはしません。 各アサーションについて、フィクスチャの状態を踏まえてスキルの記述済み指示に正しく従った場合、そのアサーションを満たすかどうかを評価します。これは Claude による推論チェックであり、コードを実行するものではありません。

各アサーションに次のいずれかを付けます。

• PASS — スキルの指示がこのアサーションを明確に満たしている
• PARTIAL — スキルの指示が一部対応しているものの、曖昧さがある
• FAIL — フィクスチャの状態を踏まえると、スキルの指示ではこのアサーションを満たさない
• NOT ASSESSED — アサーションをまったく評価できない場合。仕様で定義されていないフィクスチャの状態を指定している、静的な読み取りでは判断できない実行時の動作に依存している、または存在しないファイルやセクションを参照している場合が該当します（動作について何も記載していないだけのファイルは、NOT ASSESSED ではなく FAIL または PARTIAL とします）。順位は PASS より上（誰も評価できないアサーションは、満たされたとはいえません）、PARTIAL と FAIL より下（誰かが特定した曖昧さのほうが、誰も評価できないことより具体的で対処しやすいため）とします。スキルが「おそらく」対応しているという理由で、評価不能なアサーションを PASS にしてはいけません。その判断を置き換えることが、この仕様の目的です。

常に存在する、スキルの Protocol Compliance セクションについては、仕様に記載された各項目を、ケースのアサーションと同じ方法でスキルのファイルと照合し、PASS、PARTIAL、FAIL、NOT ASSESSED のいずれかで評価します。ケースで繰り返されないルール（「前述のプロトコル準拠アサーションで確認済み」）が仕様に含まれているため、評価されていないリストは、誰もチェックしていないルールの集まりです。リストにまだ含まれていない場合は、次の4項目を最低限追加します。

• ファイルへの書き込み前に「May I write」と確認するようスキルに求められているか
• 承認を求める前に、スキルが調査結果を提示しているか
• 推奨する次の手順でスキルを締めくくっているか
• 承認なしにファイルを自動作成しないようスキルが定めているか

Step 4 — レポートの作成

=== Skill Spec Test: /[name] ===
Date: [date]
Spec: studio-tests/skills/[category]/[name].md

Static Assertions:
  [PASS] [assertion text]
  [NOT ASSESSED] [assertion text]
     Reason: [why it could not be evaluated]

Case 1: [Happy Path — name]
  Fixture: [summary]
  Assertions:
    [PASS] [assertion text]
    [FAIL] [assertion text]
       Reason: The skill's Phase 3 says "..." but the fixture state means "..."
  Case Verdict: FAIL

Case 2: [Edge Case — name]
  ...
  Case Verdict: PASS

Protocol Compliance:
  [PASS] Uses "May I write" before file writes
  [PASS] Presents findings before asking approval
  [PARTIAL] No explicit next-step handoff at end

Overall Verdict: FAIL (1 case failed, 1 protocol line partial)

ケースの判定は、そのケースのアサーションのうち最も低い評価とします。全体の判定は、静的アサーション、ケース、Protocol Compliance のうち最も低い評価とし、順位は次のとおりです。 FAIL、PARTIAL、NOT ASSESSED、PASS。誰も評価できなかったアサーションがある場合、全体の結果を PASS にしてはいけません。

エージェントの場合、ヘッダーは === Agent Spec Test: [name] ===、Spec: は studio-tests/agents/ 配下のパスとし、Case 1 の前に Static Assertions: ブロックを置きます。

Step 5 — 結果の書き込みを提案

「これらの結果を studio-tests/results/skill-test-spec-[name]-[date].md に書き込み、studio-tests/catalog.yaml を更新してもよろしいですか？」

承認された場合：

• 結果ファイルを studio-tests/results/ に書き込みます
• studio-tests/catalog.yaml にあるスキルまたはエージェントのエントリーを更新します。
  • last_spec: [date]
  • last_spec_result: PASS|PARTIAL|FAIL|NOT ASSESSED — 全体の判定

---

Phase 2D: カテゴリモード — ルーブリック評価

Step 1 — スキルとカテゴリの特定

Phase 1 で解決したスキルまたはエージェントのファイルを使用します。 studio-tests/catalog.yaml にある、その skills: または agents: エントリーの category: フィールドを確認します。

どちらのファイルも存在しない場合：Phase 1 のメッセージを表示します。 category: フィールドがない場合：「catalog.yaml の '[name]' にカテゴリが割り当てられていません。まずエントリーに category: [name] を追加してください。」

category all の場合：category: フィールドがあるスキルとエージェントをすべて収集し、それぞれ処理して、スキルとエージェントを別々の表に報告します。 category: utility のスキルは U1（静的チェックに合格）と U2（該当する場合、ゲートモードが正しい）のみで評価します。U1 の静的モードに進み、それ以外はスキップします。 .claude/skills/*/SKILL.md および .claude/agents/*.md（Audit モードの Step 2 の glob）と照合し、カタログにないスキルまたはエージェント、あるいは category: が設定されていないものを名前ごとに NOT ASSESSED として列挙します。実行対象から黙って除外してはいけません。

ステップ 2 — ルーブリックのセクションを読む

studio-tests/quality-rubric.md を読みます。 カテゴリに該当するセクション（例：### gate、### team。エージェントのカテゴリは ## Agent Categories の下にあります。例：### director）を抽出します。 ルーブリックにカテゴリのセクションがない場合、結果は NOT ASSESSED です。欠けているセクション名を示し、他のカテゴリの指標を流用しないでください。

ステップ 3 — スキルを読む

スキルの SKILL.md と references/ フォルダー内のすべてのファイル、またはエージェントの .claude/agents/[name].md を最後まで読みます。また、プロジェクトコンテキストの Phase 2B Step 3 に記載された内容も読みます。CLAUDE.md またはそこから読み込まれるファイルのルールを満たす指標は、そのファイルを引用して満たしたものとします。リダイレクトやエスカレーションのケースに関するルールは、ドメイン、委譲、エスカレーションの指標（D2、D3、L2、S1–S3、O2）も決定します。

ステップ 4 — ルーブリックの指標を評価する

カテゴリのルーブリック表にある各指標について：

1. スキルまたはエージェントの記述された指示が、基準を明確に満たしているか確認します
2. PASS、FAIL、WARN、または NOT ASSESSED（評価できなかった指標。理由を明記）を付けます
3. FAIL／WARN／NOT ASSESSED の場合は、テキスト内の具体的な不足点を示します（該当箇所を引用する、不在を指摘する、または評価できなかった内容を示す）

ステップ 5 — レポートを出力する

エージェントの場合、ヘッダーは === Agent Category Check: [name] ([category]) === です。

=== Skill Category Check: /[name] ([category]) ===

Metric G1 — Review mode read:      PASS
Metric G2 — Director panel width:  FAIL
  Gap: Phase 3 spawns only CD-PHASE-GATE at `workflow: full`; TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE absent
Metric G3 — Lean mode: PHASE-GATE only: PASS
Metric G4 — Solo mode: no directors:    PASS
Metric G5 — No auto-advance:       PASS

Verdict: FAIL (1 failure, 0 warnings)
Fix: Size the Phase 3 panel from `modes.workflow` — PR at `minimal`, TD + PR at
     `standard`, all four at `full` — and name any perspective a narrower panel leaves out.

カテゴリの判定は、最初に該当したものを採用します。いずれかの指標が FAIL なら FAIL、そうでなく WARN があれば WARNINGS、そうでなく評価できなかった指標があれば（ルーブリックのセクションがない、ファイルを読み取れないなど）NOT ASSESSED、すべての指標が PASS なら PASS です。これは static モードおよび spec モードと同じ優先順位です。カタログでは last_category_result に記録します。

ステップ 6 — カタログの更新を提案する

「このカテゴリチェック（last_category、last_category_result）を [name] の項目として記録するため、studio-tests/catalog.yaml を更新してもよろしいですか？」

---

Phase 2C：監査モード — カバレッジレポート

ステップ 1 — カタログを読む

studio-tests/catalog.yaml を読みます。存在しない場合は、カタログがまだ存在しないこと（初回実行の状態）を記録します。

ステップ 2 — すべてのスキルとエージェントを列挙する

.claude/skills/*/SKILL.md を Glob して、スキルの完全な一覧を取得します。 各パスからスキル名（ディレクトリ名）を抽出します。

.claude/agents/*.md を Glob して、エージェントの完全な一覧を取得します。対象セットはカタログではなく、リポジトリ自体です（.claude/rules/skill-authoring.md §5：ゲートは対象セットを列挙するのではなく、そこから導出します）。両方の Glob の結果とカタログの skills:／agents: エントリーを比較し、カタログにないスキルまたはエージェントがあれば、名前を示して報告します。カタログにないものが、ひそかに対象から漏れることを防ぎます。

ステップ 3 — スキルのカバレッジ表を作成する

各スキルについて：

• spec ファイルが存在するか確認します（カタログの spec: パスを使うか、studio-tests/skills/*/[name].md を Glob します）
• カタログから last_static、last_static_result、last_spec、last_spec_result、last_category、last_category_result、category を参照します（カタログにない場合は「never」／「—」とします）
• 優先度はカタログの priority: フィールド（critical/high/medium/low）に従います

ステップ 3b — エージェントのカバレッジ表を作成する

カタログの agents: セクションにある各エージェントについて：

• spec ファイルが存在するか確認します（カタログの spec: パスを使うか、studio-tests/agents/*/[name].md を Glob します）
• カタログから last_spec、last_spec_result、last_category、last_category_result、category を参照します

ステップ 4 — レポートを出力する

=== Skill Test Coverage Audit ===
Date: [date]

SKILLS (74 total)
Specs written: 73 (99%) | Never static tested: 74 | Never category tested: 74

Skill                  | Cat      | Has Spec | Last Static | S.Result | Last Cat | C.Result | Priority
-----------------------|----------|----------|-------------|----------|----------|----------|----------
gate-check             | gate     | YES      | never       | —        | never    | —        | critical
design-review          | review   | YES      | never       | —        | never    | —        | critical
...

AGENTS (49 total)
Agent specs written: 49 (100%)

Agent                  | Category   | Has Spec | Last Spec   | Result | Last Cat | C.Result
-----------------------|------------|----------|-------------|--------|----------|----------
creative-director      | director   | YES      | never       | —      | never    | —
technical-director     | director   | YES      | never       | —      | never    | —
...

Top 5 Priority Gaps (skills with no spec, critical/high priority):
(none if all specs are written)

Skill coverage:  73/74 specs (99%)
Agent coverage:  49/49 specs (100%)

監査モードではファイルを書き込みません。

次のように提案します：「/skill-test static all を実行して、すべてのスキルの構造的な準拠状況を確認しますか？ /skill-test category all を実行してカテゴリのルーブリックチェックを行いますか？ または /skill-test spec [name] を実行して、特定の動作テストを行いますか？」

フェーズ 3：推奨される次のステップ

各モードの完了後、状況に応じたフォローアップを提示します。

• static [name] の後：「テスト仕様がある場合は、/skill-test spec [name] を実行して動作の正しさを検証してください。」
• static all で失敗があった場合：「まず NON-COMPLIANT のスキルに対処してください。詳細な修正ガイダンスを確認するには、/skill-test static [name] を個別に実行してください。」
• spec [name] が PASS の場合：「この合格日を記録するために、studio-tests/catalog.yaml を更新してください。次の仕様の不足を見つけるには、/skill-test audit の実行を検討してください。」
• spec [name] が FAIL の場合：「失敗したアサーションを確認し、不一致を解消するためにスキルまたはエージェント、あるいはテスト仕様を更新してください。」
• audit の後：「まず優先度が「critical」の不足に取り組んでください。新しい仕様を作成するには、studio-tests/templates/skill-test-spec.md の仕様テンプレートを使用してください（エージェントの場合は agent-test-spec.md）。」