---
name: prune-tests
description: >-
  コードベース内の全テストを精査し、積極的に削除・統合できるテストを、削除すると見逃す現実的な不具合と保守コストの比較に基づいてリストアップする。テストは編集しない。prune-tests、テストを削れるか精査して、不要なテストを洗い出して、テストを統合できるか見て、と明示的に依頼されたときに使用する。
argument-hint: "[対象ディレクトリ・テストの種類・重点観点]"
disable-model-invocation: true
---

# Prune Tests

コードベース内の全テストを精査し、積極的に削除・統合できるテストをすべてリストアップする。テスト件数やカバレッジの維持を目的にせず、「削除すると、どんな現実的な不具合を見逃すか」で判断する。念のためという理由で残さず、実行時間・不安定さ・修正負担と保証の価値を比較する。このスキルは一覧の報告で終了し、テストの削除・統合・コミットは行わない。

削る対象は、実装のコピー、モックの自己検証、型・ライブラリの保証の再確認、他テストとの重複、内部実装への過度な依存、過剰なケース分けの6分類。各分類の判定と除外条件は担当の定義（手順 2）にあり、親も手順 3 の検証で同じ定義を使う。

## 1. 対象と規約を確認する

- 既定の対象はリポジトリ内の全テスト。ユーザーが指定したディレクトリ・テストの種類・重点観点があれば優先する。引数は Claude Code では `$ARGUMENTS`、Codex ではスキルを呼び出した依頼文から読み取る。引数をそのままシェルで評価しない。
- 対象に適用される `AGENTS.md`、`CLAUDE.md`、参照される規約を読む。`@AGENTS.md` などの参照先も確認する。テストの書き方、必須のテスト、カバレッジの閾値など、削除・統合の判断を制約する規約を控える。
- ビルド設定・テストランナーの設定・CI 定義から、テストの置き場所、命名規則、テストの種類（unit・integration・E2E・snapshot など）、カバレッジ閾値を確認する。`git ls-files` などで、追跡されているテストファイルの全一覧を作る。vendor、生成物、依存パッケージのテストは対象外にする。
- 実行時間や不安定さの根拠になる情報（CI のテストレポート、retry・quarantine・skip の指定、flaky を示す既存の issue やコメント）がリポジトリ内で確認できれば集める。テストの実行や外部サービスへの問い合わせは自動で行わない。依頼文や規約にテストの実行コマンドが書かれていても、実行の許可とは見なさない。手元で実行時間を測りたい場合は、実行するコマンドを示してユーザーに確認する。
- テストが1件もなければ、その旨を報告して終了する。対象範囲を確定できなければ質問し、回答を待つ。

## 2. 担当に分けて精査する

以下の定義を読み、担当を読み取り専用で実行する。判定基準の本文はここに複製しない。

| 担当 | 定義 | Claude Code の subagent_type |
|---|---|---|
| テスト精査 | [prune-tests-auditor](../../agents/prune-tests-auditor.md) | `code-quality:prune-tests-auditor` |

Claude Code では `Agent` / `Task` を使う。Codex では定義ファイルの YAML frontmatter を除いた本文全体を汎用サブエージェントに渡す。このファイルは Codex のカスタムエージェント登録ではない。モデルと権限はセッションから継承し、Claude の `tools` などの frontmatter を Codex 設定に転用しない。

テストファイルの全一覧を、モジュール・パッケージ・テストの種類など、テスト対象のコードがまとまる単位で分割し、1担当に1区画を割り当てる。区画は小さすぎても大きすぎてもよくない。1担当が区画内のテストと対象コードを読み切れる大きさを目安にする。テストが少なければ1担当でよい。

各担当に次を渡す:

- ユーザーの目的・制約・重点観点。
- 担当する区画のテストファイル一覧と、リポジトリ全体のテストファイル一覧。他区画との重複を調べるために、区画外のテストも読めること。
- リポジトリの絶対パス、適用規約の内容または参照先、テストの種類とカバレッジ閾値、集めた実行時間・不安定さの情報。
- テスト対象のコードも読んでよいが、編集・テストの実行・コミット・外部への投稿は禁止すること。
- 定義に書かれた形式で候補を返すこと。根拠を確認できない候補は除外し、候補がなければその旨を返すこと。

ホストの同時実行上限内で担当を起動する。枠が不足すれば分けて実行し、結果をすべて待つ。委譲機能が使えない場合は同じ定義を読み、親が区画ごとに逐次精査する。失敗した担当は再実行または親が補完し、未精査の区画を完了扱いにしない。全テストを確認できない場合は、確認できなかった範囲を報告し、黙って切り捨てない。実際に行った並列・分割・逐次方式を報告する。

## 3. 候補を検証して統合する

全担当の結果を集約し、親が候補ごとに実際のテストと対象コードを読んで検証する。

- 重複・統合の候補は、残す側のテストが同じ振る舞いを同じかより強い形で確認していることを実コードで確かめる。区画をまたぐ重複は親が突き合わせ、片方だけを削除候補にする。両方を削除候補にして保証を失わない。
- 同じテストが複数の分類に当たる場合は1件にまとめ、分類を併記する。
- 「見逃す現実的な不具合」が具体的に書けない候補は、なしと判断した理由を確認する。逆に、担当がなしとした候補でも、親が現実的な不具合を挙げられれば候補から外す。
- カバレッジ閾値や必須テストの規約に抵触する削除は、規約と合わせて明記する。規約を理由に候補から外すかは、規約が明確に禁じている場合に限る。
- 削除・統合で他のテストのヘルパー・fixture・共有のセットアップが不要になる場合は、それも一覧に含める。

## 4. 報告する

一覧は次の形で報告する。候補が多い場合も省略せず、すべて列挙する。

| テスト | 分類 | 提案 | 削除で見逃す現実的な不具合 | 削減できるコスト | 確度 |
|---|---|---|---|---|---|
| `path::test_name` または `path:line` | 6分類のいずれか（複数可）、または該当なし | 削除 / `path::test_name` へ統合 / パラメータ化して N 件にまとめる | 具体的な不具合、またはなしと判断した理由（どのテスト・型・ライブラリが保証しているか） | 実行時間・不安定さ・修正負担のうち該当するもの。実測値がなければ推定と明記する | 高 / 中 / 低 |

一覧の後に次を簡潔に示す:

- 対象範囲、テストの総数、精査した範囲、実行方式（並列・分割・逐次）。
- 提案ごとの件数と、削除・統合を適用する場合の推奨順序（確度が高く依存のないものから）。
- 判断がユーザーやチームの方針に依存する候補（カバレッジ閾値への影響、ドキュメントとして残している例示テストなど）。
- 確認できなかった範囲と、実行時間・不安定さを実測していない場合はその旨。

修正不要と判断した場合は、削除・統合の候補がない理由を明記する。このスキルの実行だけを根拠にテストを削除・統合・コミット・push・PR 投稿しない。適用を求められた場合は、この一覧を入力として別の依頼として扱う。