test-review

テストレビュー

まずプロジェクトのテスト規約を読み込んでから監査ワークフローを実行し、テストの品質をレビューしてカバレッジの不足を監査します。パイプラインでは、優先順位を付けた不足レポートを作成します。テストコードは作成しません。

使用する場面

• 「モジュール X のテストをレビューして」
• 「このコンポーネントのテストカバレッジを監査して」
• 「これらのテストは適切ですか？」
• 「不足しているテストは何ですか？」
• 新しいテストを書く前（まず監査し、その後で作成します）
• 大規模なリファクタリングの後（テストが引き続き仕様をカバーしているか確認します）
• モジュールを本番環境に向けて準備するとき

パイプライン

このスキルは3フェーズのパイプラインです。各フェーズを順番に実行してください。フェーズ1を省略しないでください。テストコードをレビューする前に、規約を読み込む必要があります。

共有レビューインフラストラクチャ。 テスト規約と監査ワークフローの参照資料は skills/agent-loops/references/ にあり、コミットごとのテストカバレッジ確認で同じ仕様を使用する agent-loops スキルと共有されています。両方のスキルは同じ情報源を参照し、内容のずれを防ぎます。

フェーズ1：規約を読み込む

プロジェクトのテスト規約を読み、「適切なテスト」の基準を確認します。

cat skills/agent-loops/references/testing-standards.md

このファイルでは、以下を定義しています。

• 指摘すべきアンチパターン（ミラーリングテスト、ハッピーパスのみのテスト、過剰なモック、些細なアサーション）
• 必須のテストカテゴリ（コントラクト、境界、失敗モード、状態遷移、統合）
• 個々のテストのセルフチェックリスト
• 言語固有の規約（Rust、TypeScript/React）
• コンポーネントの種類ごとのカバレッジ要件
• 命名規則

テストコードを読む前に、これらの内容を理解してください。 監査でのすべての指摘は、このファイルに定められた具体的な規約を参照する必要があります。規約を独自に作らず、ここで定義されたものを使用してください。

フェーズ2：検出（Haiku エージェント）

Haiku サブエージェントを起動し、監査ワークフローのステップ1と2にあたる機械的な検出作業を行います。これにより、メインのコンテキストを分析に集中させられます。

エージェントに必要な作業を把握するため、まず監査ワークフローを読んでください。

cat skills/agent-loops/references/audit-workflow.md

ステップ2a：作業範囲を決める

エージェントを起動する前に、対象ファイルの数を確認します。

Glob tool: **/*.{py,rs,ts,tsx,js,jsx,go,rb} under [MODULE_PATH]
Glob tool: **/*.{test,spec}.* or **/test_*.* or **/tests/**  under [TEST_PATH]

ソースファイルとテストファイルの数を数えます。これに基づいて、作業の分割方法を決めます。

ステップ2b：作業の分割方法を選ぶ

ソースファイル	方法	エージェント数
≤ 15	単一エージェント — Haiku がすべてを担当	1
16–60	ディレクトリ単位で分割 — トップレベルのサブディレクトリ（または論理的なグループ）ごとに1エージェント	2–4
60+	ファイル群に分割 — ファイルリストをおよそ15ファイルずつのほぼ均等なグループに分ける	最大6

分割ルール：

• 各エージェントには、一覧化するソースファイルの一部を割り当てます（ステップ1）
• 各エージェントには、テストファイルの全リストも渡します（テストはソースファイルの境界をまたぐ場合があります）
• 各エージェントは、割り当てられたソースファイルのみを一覧化します
• 可能な限りディレクトリの境界に沿って分割し、関連するファイルをまとめます

ステップ2c：エージェントを並列で起動する

すべての Haiku エージェントを1つのメッセージで起動し、並行して実行します。各エージェントには同じ指示を与えますが、割り当てるファイル群は変えます。

Haiku エージェントに、分析、優先順位付け、判断を依頼しないでください。 エージェントの役割は、コードを読み、事実に基づいた一覧を作成することです。分析はフェーズ3で行います。

単一エージェント（ソースファイルが15以下の場合）：

Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/agent-loops/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the module at [MODULE_PATH].

    Step 1 - Map the Public Contract:
    Read every source file in the module. List every public behavior it promises
    as plain-English statements (see audit-workflow.md for format and examples).

    Step 2 - Map Existing Test Coverage:
    Read every test file that covers this module. For each test, record what
    behavior it exercises and whether assertions are meaningful. Mark each
    behavior from Step 1 as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files read (paths)
    2. Test files read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.

複数エージェント（ソースファイルが16以上の場合）：

すべてのエージェントを同じメッセージで起動します。各エージェントには、ソースファイルの一部とテストファイルの全リストを渡します。

# Agent 1 of N — launched in parallel with all other agents
Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/agent-loops/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the following SOURCE FILES ONLY:
    [LIST OF FILES IN THIS PARTITION]

    The test files that may cover these sources are at:
    [FULL TEST FILE LIST OR TEST DIRECTORY PATH]

    Step 1 - Map the Public Contract:
    Read ONLY the source files listed above. List every public behavior each
    promises as plain-English statements (see audit-workflow.md for format).

    Step 2 - Map Existing Test Coverage:
    Read the test files and identify which tests exercise behaviors from YOUR
    source files. Mark each behavior as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files you read (paths)
    2. Test files you read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.

# Agent 2 of N — same structure, different file partition
# ...
# Agent N of N

Step 2d: インベントリを統合する

すべてのエージェントから結果が返されたら、それらを1つの統合インベントリにまとめます。

1. 連結：すべての動作リストを連結します（各エージェントは異なるソースファイルを担当するため、重複は最小限のはずです）。
2. 重複を除去：複数のエージェントの結果に含まれる動作を重複として除去します（異なるパーティションのソースファイルでインターフェースが共有されている場合に発生することがあります）。
3. 重複がある場合は、より具体的なステータスを優先：あるエージェントが Covered、別のエージェントが同じ動作を Shallow としている場合は、Shallow を残します（Phase 3 で食い違いを調査します）。
4. 全エージェントが読み込んだソースファイルとテストファイルの一覧を作成します。

統合したインベントリは、1つのエージェントが作成した場合と同様に、そのまま Phase 3 に引き継がれます。

Phase 3: 分析とレポート

統合した Haiku インベントリを使い、あなた（メインエージェント）が監査ワークフローの Steps 3 と 4 にあたる詳細な分析を行います。

• Step 3: 敵対的分析 — 入力境界、エラー処理、状態、統合部分を調査します。監査ワークフローにある質問を動作インベントリに照らして確認します。回答のために特定のソースファイルを読む必要がある場合があります。
• Step 4: ギャップレポートの作成 — audit-workflow.md で定義された基準を使って P0/P1/P2 の優先度を割り当て、testing-standards.md のルールを引用し、指定された形式で完全なレポートを作成します。

敵対的分析と優先度の割り当てには、メインエージェントのみが行うべき判断が必要です。これらをサブエージェントに委任しないでください。

運用ルール

1. 常に基準を最優先します。 テストファイルを開く前に testing-standards.md を読みます。コンテキストが圧縮され、基準が読み込まれていない場合は、もう一度読み込んでください。

2. 修正ではなく、報告します。 出力はギャップレポートです。承認済みレポートに基づく特定のギャップの実装を明示的に依頼された場合を除き、テストコードを書かないでください。

3. 基準を引用します。 すべての指摘で、違反している testing-standards.md のルール、または満たしていない audit-workflow.md の基準を明示します。引用のない指摘は意見であり、監査結果ではありません。

4. テストだけでなく、ソースコードを読みます。 監査では、公開コントラクトを把握するためにモジュールのソースコードを読む必要があります（audit-workflow.md の Step 1）。テストだけを切り離して監査しないでください。コードの動作とテストで検証されている内容のギャップを見つけることが、監査の目的です。

5. ギャップを捏造しないでください。 モジュールが十分にテストされている場合は、その旨を伝えてください。ギャップレポートには、まさにそのための「十分にテスト済み」セクションがあります。

モード

完全監査（デフォルト）

3つの Phase すべてを実行します。完全なギャップレポートを作成します。

使用する場合：「モジュール X のテストを監査」「テストカバレッジをレビュー」「本番環境への準備」。

クイックレビュー

testing-standards.md を読み込んでから、アンチパターンとセルフチェックリストに照らして、指定されたテストファイルのみをレビューします。Phase 2（Haiku による検出）と敵対的分析はスキップします。

使用する場合：PR のテスト変更をレビューする場合、単一のテストファイルをスポットチェックする場合、「このテストで問題ありませんか？」。

作成モード

まず完全監査を実行してギャップレポートを提示します。その後、承認を得た場合に限り、testing-standards.md の基準に従って、承認されたギャップを埋めるテストを実装します。

使用する場合：「モジュール X のテストを監査して修正」「不足しているテストを書いて」。

よくある間違い

• testing-standards.md を読み飛ばす — 基準を読み込まずにテストをレビューすると、一般論に終始したフィードバックになります。基準はこのプロジェクト固有であり、明確な方針を持っています。
• レポート作成前にテストを書く — 監査では指摘事項を提示します。どれを実装するかはユーザーが決めます。先走らないでください。
• ソースを読まずにテストを監査する — コードの動作を把握せずに、カバレッジの不足を特定することはできません。
• 根拠なしに重大度を割り当てる — P0/P1/P2 の割り当てには、audit-workflow.md で定義された具体的な基準があります。直感ではなく、その基準を使用してください。