菜单
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。
大きな計画や実装タスクを、依存関係順に並んだ最小単位のステップに分解します。各ステップは単独でレビュー・コミットできる粒度にします。「分解して」「ステップに割って」「細かく割り当てたい」「着手前に整理したい」「段階的に進めたい」「タスクを整理して」と要望された際に使用します。
| 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"] |
既存テストを.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 |
ユーザーの指示から対象を決めます。
findで列挙し、以下の条件に当てはまるものを対象とします
*.test.ts / *.test.tsx / *.spec.ts — テストファイル*.md — テストコードブロック（```tsや```tsx）を含むドキュメントファイル。コードブロックが存在しないmdファイルは対象外です.md ファイルをレビューするときは、文章部分ではなくコードブロック内のテストコードに対してルールを適用します。
テスト対象に対応する計画ドキュメントをプロジェクト内で自律的に探します。docs/・doc/・spec/・specs/・design-doc/・design-docs/・.claude/docs/等の一般的なドキュメントディレクトリをGlob/Bashで検索し、テスト対象のファイル名やモジュール名に対応するMarkdownファイルがあるか確認します。
同じ周回を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周通して参照し続けて構いません。
そのうえで、各周回で次を実施します。
2周目以降の重要事項: 前の周回で「直さなくてよい」「こう直した」と判断した内容を引きずらないようにします。前周の差分や自分のメモを参照せず、毎回テストファイルとソースコードを白紙から読み、各観点を満たしているかをゼロベースで評価します。
設計の匂いを検出した場合: ルールへ合わせるためテスト側を曲げざるを得ないケースが該当します。次のようなケースでは、テストを直すのではなくプロダクトコード側の設計問題として記録します。
as anyやprivate暴露が必要判断基準は.claude/docs/test-implementation.mdの「テストが書きにくいと感じたら設計の匂いを疑う」節にあります。
3周すべてを完了するまでこのフェーズを終えません。
3周分の修正内容と最終的な状態をユーザーに報告します。観点ごとに整理して伝えると見通しがよくなります（テスト名・AAA構造・アサーション・テストダブル・非決定性・フロントエンド固有のルールなど）。設計の匂いを検出した箇所は、テスト修正とは分けてプロダクトコード側の課題として報告します。カバレッジ不足のケース追加は、手順2で計画ドキュメントを参照できた場合に限って行います。