| name | x-test-review |
| description | 既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。 |
| context | fork |
| allowed-tools | ["Bash","Read","Edit","Glob","Grep","TaskCreate","TaskUpdate","TaskList"] |
Test Review
既存テストを.claude/docs/test-implementation.mdのテスト実装ルールに沿わせるためのスキルです。新しいテストを書く用途には使いません。
評価の対象
主軸はテスト実装ルール全観点への準拠で、ユースケースのカバレッジは補助的に見ます。
テスト実装ルールへの準拠（中心）
具体的な観点は.claude/docs/test-implementation.mdに書かれています。観点には、テスト名の表現・AAA構造・1テスト1Act・期待値のハードコード・観測可能な出力のみのアサート・テストダブルの役割分離・モック対象の選定・非決定性の制御・テスト間の独立性・診断性・フロントエンド固有のルールなどが含まれます。これを一次情報として扱い、レビューのたびに読み直します。
日本語表現は次の2つのファイルも併せて参照します（テスト名やテスト内の文字列の言い回しに適用）。
.claude/agents/japanese-writing-review/rule-japanese-expressions.md.claude/agents/japanese-writing-review/rule-structure.md
ユースケースカバレッジ（補助）
ルール準拠の確認が終わったあとで、明らかに抜けているケースがあれば指摘します。既存のテストケースを正として扱うのが基本です。正解の判断は次の順で行います。
- 自律的な検索またはユーザーの案内で計画ドキュメントが見つかった場合 → そちらを一次情報とします
- 検索しても見つからず、ユーザーも把握していない場合 → 既存のテストケースをユースケースの正解として扱い、カバレッジ評価は行いません
タスク登録（実行開始時に必ず実施）
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|
| 1 | 対象ファイルを特定する | — |
| 2 | 計画ドキュメントを探す | 1 |
| 3 | レビューを3周実施する | 2 |
| 4 | 結果を報告する | 3 |
手順
1. 対象ファイルを特定する
ユーザーの指示から対象を決めます。
- ファイル指定 → そのファイル
- ディレクトリ指定 → 配下を
findで列挙し、以下の条件に当てはまるものを対象とします
*.test.ts / *.test.tsx / *.spec.ts — テストファイル*.md — テストコードブロック（```tsや```tsx）を含むドキュメントファイル。コードブロックが存在しないmdファイルは対象外です
- 指定なし → ユーザーに「どのファイル・ディレクトリを対象にしますか？」と確認します
.md ファイルをレビューするときは、文章部分ではなくコードブロック内のテストコードに対してルールを適用します。
2. 計画ドキュメントを探す
テスト対象に対応する計画ドキュメントをプロジェクト内で自律的に探します。docs/・doc/・spec/・specs/・design-doc/・design-docs/・.claude/docs/等の一般的なドキュメントディレクトリをGlob/Bashで検索し、テスト対象のファイル名やモジュール名に対応するMarkdownファイルがあるか確認します。
- 見つかった場合 → Readしてユースケースを把握し、テストがそれをカバーしているかを見ます
- 見つからなかった場合 → ユーザーに「計画ドキュメントが見つかりませんでした。パスをご存じであれば教えてください」と確認します
- ユーザーがパスを教えてくれた場合 → Readしてユースケースを把握し、テストがそれをカバーしているかを見ます
- ユーザーも把握していない場合 → カバレッジ評価はスキップし、ルール準拠の改善のみを行います
3. レビューを3周実施する
同じ周回を3回繰り返します。1周目で網羅したつもりでも、2周目・3周目で見え方の変わるときがあるためです。
まず、以下の3つのルールファイルをReadします。
.claude/docs/test-implementation.md.claude/agents/japanese-writing-review/rule-japanese-expressions.md.claude/agents/japanese-writing-review/rule-structure.md
ルールは周回のあいだに変わらないので、ここで読んだ内容を3周通して参照し続けて構いません。
そのうえで、各周回で次を実施します。
- 対象のテストファイルとテスト対象のソースコードをReadで読み直します（ルールファイルは読み直さなくてよい）
- ルールファイルの観点をすべて当てはめて評価し、合わない箇所があればEditでファイルに反映します
- 直す箇所がなければ「現状で問題なし」として次の周回へ進みます
2周目以降の重要事項: 前の周回で「直さなくてよい」「こう直した」と判断した内容を引きずらないようにします。前周の差分や自分のメモを参照せず、毎回テストファイルとソースコードを白紙から読み、各観点を満たしているかをゼロベースで評価します。
設計の匂いを検出した場合: ルールへ合わせるためテスト側を曲げざるを得ないケースが該当します。次のようなケースでは、テストを直すのではなくプロダクトコード側の設計問題として記録します。
- 大量のモックが必要
- Arrangeが極端な長さ
as anyやprivate暴露が必要- 観測可能な出力がなく内部状態への依存が必要
判断基準は.claude/docs/test-implementation.mdの「テストが書きにくいと感じたら設計の匂いを疑う」節にあります。
3周すべてを完了するまでこのフェーズを終えません。
4. 結果を報告する
3周分の修正内容と最終的な状態をユーザーに報告します。観点ごとに整理して伝えると見通しがよくなります（テスト名・AAA構造・アサーション・テストダブル・非決定性・フロントエンド固有のルールなど）。設計の匂いを検出した箇所は、テスト修正とは分けてプロダクトコード側の課題として報告します。カバレッジ不足のケース追加は、手順2で計画ドキュメントを参照できた場合に限って行います。
