tidy

Tidy

差分をレビューし、依頼されたら修正します。1回の実行でレポートを作成します。適用モードでは同じ実行中に修正を反映し、きれいな差分に隠れている簡素化も行います。

• 対象: ローカルの差分、ブランチの差分、PR、または指定されたセキュリティ範囲のレビュー。file:line の根拠と重大度別の指摘を返します。適用モードでは、それらの指摘に対する最小限かつ完全な修正に加え、差分の範囲内で簡素化します。
• 対象外: PR の作成（pr-creator）、CI の失敗やレビューコメント（pr-babysitter）、ユーザー向け UX、アクセシビリティ、レンダリング品質（ui-design の Audit モード）、ライブラリや CLI の使いやすさ（dx-audit）、アーキテクチャの概要やリポジトリ全体のガードレール（codebase-architecture）、計画のレビュー（planning）、測定済みの目標値に合わせたテストスイート全体の削減（test-audit）。

レポートまたは適用

レポートがデフォルトです。「変更をレビューして」「コードレビュー」、以下のモードフレーズ、または PR 番号が指定された場合に実行します。完了時には、Output の形式でレポートを返します。レビューした範囲、各ベースラインコマンドの最終行、参照した資料も記載します。作業ツリーは変更しません。レポートモードでは、1文字だけの修正であってもファイルを編集してはいけません。ツリーを変更した時点で、ユーザーが求めた読み取り専用のレポートではなくなるためです。

適用は、ユーザーが「tidy」「simplify」「fix」「指摘を適用して」と言った場合、または変更を依頼した場合に実行します。完了時には、確認済みの指摘と根拠のある簡素化が作業ツリーに反映され、影響を受けるチェックが通るか、失敗がベースラインによるものだと示されている状態にします。また、変更内容、未対応の項目とその理由、チェック結果をまとめます。適用モードでは、差分の対象ファイル、または修正に必要なファイルを編集し、リポジトリでドキュメント化された lint、型チェック、テストのコマンドを確認せずに実行します。これらは作業ツリーに対してローカルで実行され、変更の反映自体が依頼されているためです。コミット、プッシュ、PR の作成、依存関係の追加やアップグレード、マイグレーションの実行、作業ツリー外への書き込みは行いません。セッションの前半で作成したレポートは入力情報であり、決定を拘束するものではありません。現在の根拠で裏付けられる内容を適用し、適用しなかった項目については理由を説明します。

ハーネスの優先順位

Claude Code には /code-review（正確性とクリーンアップ。--fix 対応）および /security-review が同梱されています。入力されたスラッシュコマンドは同梱スキルを実行します。このスキルは名前が指定された場合、またはモードフレーズが一致した場合に実行されます。さらに、Structural モードと Deslop モード、リポジトリ全体を対象とする Security 監査、同梱コマンドで除外される妥当性のある重大度レベル、REVIEW.md のサポート、git とファイルツールがある任意のハーネスで同じレポートを作成する機能を追加します。このセッションですでに実行された同梱レビューの指摘は、再導出するのではなく、判定ステップで候補として扱います。

モードの振り分け

ユーザーの表現に基づいて、いずれかの観点を選びます。references/severity-rubric.md はすべてのモードで読み込まれ、表に記載された各モード固有のルーブリックが追加で読み込まれます。

モード	トリガー	追加されるもの	対象範囲
Standard（デフォルト）	/tidy、「変更内容をレビューして」、「コードレビュー」、「これを整理して」	なし	ローカルまたはブランチの差分
Structural	「構造レビュー」、「徹底的なレビュー」、「コード品質の詳細監査」、「保守性の厳しいレビュー」、「コード柔道」	references/structural-quality-rubric.md	ローカルまたはブランチの差分
Deslop	「これを整理して」、「AI コードをクリーンアップして」、「余計なコードを削除して」、「AI のパターンがないかレビューして」	references/ai-slop-patterns.md	ローカルまたはブランチの差分
Security audit	「セキュリティ監査」、「脆弱性を探して」、「deepsec」、「脅威モデル」、「セキュリティ監査をして」	references/security-checklist.md	差分の有無にかかわらず、指定されたサブシステムまたはリポジトリ全体

どのモードでも、次の場合は条件に応じて追加で読み込みます。

• 差分がエージェントによって作成された場合、またはモジュール、システム境界、ガード、フォールバックを追加、変更、削除する場合は、references/context-errors.md を読み込みます。
• 認証、入力処理、外部 API、アップロード、依存関係やロックファイルの変更、環境設定に関わる場合は、references/security-checklist.md を読み込みます。
• フェッチ、レンダリング、画像、依存関係、バンドルに影響するインポートに関わる場合は、references/performance-checklist.md を読み込みます。
• 差分でテストを追加または変更する場合は、references/test-gate.md を読み込みます。テストの変更がない差分では、ここで追加の読み込みは行いません。
• agents/openai.yaml は、ステップ 3 の任意のセカンドオピニオン確認でのみ読み込みます。それ以外の場合は外部ランナー用のランチャーメタデータであり、読み込まれることはありません。

ワークフロー

1. 対象を特定します。 まずステージ済みおよび未ステージの変更を確認します（git diff --stat、git diff --staged --stat）。変更がなければ、git merge-base HEAD origin/<default> に対するブランチの差分を確認します。PR の場合は、該当ブランチをチェックアウトした状態で gh pr diff <n> を実行します。範囲または参照ペアを記録し、レポートに記載します。

2. コンテキストを収集します。 ファイルツールを使って、モードのリファレンスと条件付きで読み込まれるファイルを開きます。このスキル内のファイル名は参照先であり、内容が読み込まれていることを意味しません。必要なファイルを読み込めなかった場合は、ルーブリックを適用したと主張せず、確認できていない範囲を報告します。ユーザーの言葉、コミットメッセージ、PR の説明から意図を把握します。該当範囲の AGENTS.md / CLAUDE.md と、存在する場合はルートの REVIEW.md を読み込みます。これらは矛盾する場合にこのスキルの既定値より優先されるため、そこで義務付けられているパターンは指摘対象ではありません。このリビジョンですでに実行済みのチェックは再利用します。候補の検証に実行が必要な場合は、文書化されたコマンドを実行し、終了ステータスを保持します。

3. レビューします。 読み込んだルーブリックと重要度の高い基準を適用し、大きな差分は分割して確認します。各パスで見つかる問題が異なるため、次の 5 つのパスを実施します。

   • 主張。 説明またはコミットメッセージ内の各主張を該当する差分に対応付け、各差分を主張に対応付けます。対応する差分のない主張は指摘事項です。主張のない差分は、準備状況の要約に明記されていない変更として記載します。
   • 追加行。 すべての差分を読み、その差分を含む関数全体を確認します。変更された関数内の未変更行にあるバグも対象です。この差分によって再び問題になったためです。
   • 削除行。 削除または置換された行ごとに、その行が守っていた不変条件を特定し、新しいコードでその条件がどこで再確立されるかを確認します。確認できなければ、それが指摘事項です。削除されたガード、失われたエラー処理、狭められた検証、実際のケースを網羅していた削除済みテストなどが該当します。
   • 呼び出し箇所。 変更された各関数について、呼び出し元を検索し、新たな事前条件、戻り値の形式の変更、新たな例外、順序依存性がないか確認します。その後、呼び出し先も確認します。
   • 差分の外側。 新しいモジュール、ガード、フォールバックごとに、差分で開かれなかった箇所を確認します。具体的には、そのディレクトリの既存のエクスポート、同階層の実装、ガード対象の値を書き込むすべての箇所です。ヘルパーの再実装、誤ったシステムへの変更、どの状態からも発生しない状態を対象とするフォールバックは、差分で開かれなかったファイルを確認するまでは、いずれも問題のないコードに見えます。references/context-errors.md に、検索方法と、各指摘に必要な証拠が記載されています。

   このセッションで差分を作成した場合、コードだけでは明らかにならない意図を把握できます。範囲とユーザーの依頼をそのまま渡した新しいサブエージェントで各パスを実施します。変更内容についてのあなた自身の説明は渡さないでください。ステップ 4 で候補を判定します。

   オプション：別モデルの CLI（codex exec、droid exec など）が利用できる場合は、agents/openai.yaml の default_prompt を使い、読み取り専用で実行します。その指摘も自身の指摘と同様に判定します。見解の一致は裏付けにはなりません。どちらも同じ差分を、同じ不足したコンテキストのまま読んでいるためです。

4. 判定します。 候補はすべて、確定、可能性あり、反証済みのいずれかに分類します。確定の場合は、問題を引き起こす入力または状態と誤った出力を特定し、該当行を引用します。可能性ありの場合は、仕組みが実在する一方で発生条件が不確かであることを説明し、何を確認すれば確定できるかを述べます。反証済みの場合は、事実に反するか、すでにガードされていることを示し、証明する行を引用します。可能性ありを既定とします。並行処理の競合、まれだが到達可能な経路での nil、falsy なゼロ値を未設定と扱う問題、除外されていない境界での off-by-one、アンカーを失った正規表現はいずれも現実的な懸念です。コードで反証できる場合にのみ反証済みとします。重複、誤った帰属、変更された関数の外にある既存の問題は除外します。references/test-gate.md の指摘も、独立したセクションではなく同じ 2 つの分類に含めます。

5. 報告または適用します。 Output に従って報告し、構造上のブロッカーは Must fix before push に記載します。可能性ありの指摘には、その旨を明記します。適用モードの場合は、以下に続けます。

適用

原因ごとに指摘事項をまとめます。まず正確性の修正、次に所有権の修正、その後に残ったものを簡素化します。確認済みの指摘事項に加えて、差分を次の5つの観点で確認します。

観点	問い	変更の根拠
再利用	このコードは本当に必要ですか。それともリポジトリのヘルパー、標準ライブラリ、プラットフォーム機能、インストール済みの依存関係で対応できますか。	既存の契約と呼び出し箇所、およびそこで処理される境界ケース
品質	状態を管理する主体の重複、使われていない拡張ポイント、不要な互換性対応が追加されていませんか。	行数ではなく、実際の利用者と状態の所有権
効率	実際のホットパスで処理が繰り返されていませんか。	呼び出し頻度、重複した読み取り、上限のない保持
所有権	呼び出し元のパッチが共有メカニズムの不備を補っていたり、この振る舞いを所有するサブシステムの外に配置されていたりしませんか。	書き込み元、呼び出し元、隣接する実装。根本的な修正は特例より小さくなければなりません
テストの価値	誰かが対処すべき理由によって、このテストは失敗しますか。	名前の付いた回帰、到達可能な分岐、公開された契約。差分のリテラルな複製やモックのエコーには価値がありません

制約：

• ガードの削除にはシステム上の根拠が必要です。 フォールバック、リトライ、ロック、バリデーションを削除する前に、書き込み元、到達可能な状態、許容される古さ、復旧の責任者を特定してください。状態を排除できない場合は残し、不確実性を報告してください。
• 無関係な編集をファイル全体のロールバックで取り消さないでください。 フォーマッターの適用範囲を限定してください。git restore <path> は同じファイル内でユーザーが先に行った編集を破棄します。
• 抽象化のノルマはありません。 行数が減っても、異なるライフサイクルが隠されたり、振る舞いが失われたりするなら改善ではありません。好みの汎用パターンより、既存の所有サブシステムを優先してください。
• テストはリスクに応じて追加します。 編集によって単独で回帰し得る振る舞いが変わる場合は、回帰チェックを追加または更新してください。コピー、リテラルな設定変更、別の場所でカバーされているフレームワークの振る舞いには不要です。
• 確認済みのテストゲート指摘事項は削除または書き換えてください。 新規または変更したテストが、確認済みの段階で references/test-gate.md に違反する場合、そのテストを差分に残してはいけません。削除するか、ゲートで指定された境界で書き換えてください。ゲート違反の可能性がある指摘は報告し、自動的に削除しないでください。
• 根拠が得られたら止めてください。 影響を受けるチェックに合格したら、新たな変更や未解決の懸念がある場合に限り、再度確認してください。同じ箇所にガードを追加し続ける2回目の確認は、問題がガードではなくメカニズムにあることを示しています。よりシンプルな形をシステムの担当者に提示してください。

変更の影響を受けるチェックと、リポジトリで必須のゲートを実行してください。終了コードを保持し、ベースラインの失敗と区別したうえで、「Report or apply」に記載された形式で概要を作成してください。

高いシグナルの基準

以下のいずれかに該当するものはすべて挙げ、判定ステップに判断させてください。信頼度で事前に絞り込まないでください。フィルターが二度実行され、二度目のパスでは一度目に除外されたものが見えなくなります。

• コンパイル、型、インポート、構文の失敗、またはインストール済みの依存関係のバージョンでエクスポートされていないシンボルの呼び出し（node_modules/<pkg> またはロックファイルに記載されたバージョンのドキュメントを確認してください）。
• 捕捉したエラーの破棄：空の catch、ログを出力してから成功パスに進むもの、あるいは失敗によって呼び出し元の処理が変わるべき Promise に対する .catch(() => {})。
• 脆弱性の種類と該当する file:line を示した、具体的な悪用経路。
• 必要なテストの欠如：インタラクティブな動作に対するレンダーのみのチェック、または失敗した継ぎ目での失敗再現テストを伴わないバグ修正。
• 利用側が存在しない、または到達不能な足場コード。見つからなかったことを示す検索内容を記載し、利用側が生成される可能性、規約によって呼び出される可能性、またはこのリポジトリ外に存在する可能性がある場合は、もっともらしい事象として示してください。検索結果が空でも証明にはなりません。動的インポート、ファイル名の規約、生成コード、他のリポジトリなど、静的検索では見つからないコードに到達する方法があります。
• デプロイ環境では発生しない状態を対象とするガード、フォールバック、再試行、または鮮度維持の仕組み。報告する場合は、書き込み元の集合、利用側の許容範囲、または再起動ポリシーを明記してください。
• ベースラインと比較して新たに発生した lint、型チェック、またはテストの失敗。
• スコープが適用される指示ファイルまたは REVIEW.md への違反。該当するルールを引用してください。
• 冪等性キーのない再試行または少なくとも 1 回の書き込み、outbox のないデータベースコミットと外部公開、未加工バイトに対する署名を検証せずに信頼する Webhook、金額への浮動小数点数の使用、構造化されていない文字列としてのタイムスタンプ、補償経路のない不可逆な処理を含む複数ステップのフロー、監査証跡のない機密性の高い変更。

構造的なチェックは Standard を含むすべてのモードで適用されます。該当するのは、修正を本来あるべき階層より上に追加すること（すべての呼び出し元に対応するコード内で、ある呼び出し元だけを対象にした特殊ケースを設けること、または呼び出し元すべてに適切な形式を返せる関数があるのに、呼び出し箇所のひとつだけにガードを設けること）、現在の要件がない段階での抽象化の先取り、新しい動作にローカルな境界があるにもかかわらずファイルが約 1000 行を超えること（設定済みの max-lines がある場合はそちらを優先します）、共有パス内の機能固有の条件分岐、標準ユーティリティと重複する独自ヘルパーまたは標準ライブラリの再実装、すでに導入済みのものに対する新たな依存関係、誤ったレイヤーへのロジックの配置です。references/structural-quality-rubric.md では、それぞれについて Structural モード向けに詳しく説明しています。

スタイル上の好み、無関係な既存の問題、再現手順や悪用経路のないリスク、差分の意図を超える広範な書き換え、リンターのみのノイズ、明示的に抑制された違反は報告しないでください。

出力

各指摘には file:line、影響を示す 1 行、コミット可能な修正を含めてください。もっともらしい指摘には Plausible: <確認に必要な内容> を追加してください。差分外の情報に基づく指摘には、その成果物を明記する Context: を追加してください。「リファクタリングを検討してください」という形式の Fix: は適用できません。変更内容を記述してください。長さは指摘の数に応じて調整します。問題のない差分では、None. を 2 回記載し、準備状況ブロックを付けてください。

## Local review

### Must fix before push
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <concrete impact>
  Fix: <committable fix>

### Should fix soon
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <concrete impact>
  Fix: <committable fix>
  Plausible: <what would confirm it>

### Ready for handoff
- Reviewed: <range or ref pair>, <N> files
- Baseline: `<command>` -> <last line>
- Mode: <selected mode>
- Reference evidence: `<path opened>` -> "<short excerpt>"
- Missing reference coverage: <failed reads, or None>
- Unstated changes: <hunks no claim covers, or None>
- <readiness verdict>

pr-babysitter または gh を通じて PR の引き継ぎを投稿する場合は、## PR handoff summary の下に同じ指摘形式を使用し、minor 項目には Nit: を付けてください。apply モードでは、報告の後に、適用した内容、残した内容とその理由、チェック結果を記載してください。

注意点

• 新しいブランチでは git diff @{u} は「上流が設定されていません」というエラーで失敗し、古いチェックアウトで main との差分を取ると、ほかの人のコミットまで含まれます。git merge-base HEAD origin/<default> との差分を取り、対象範囲を明記してください。
• git diff のハンクヘッダーから数えた行番号は、ハンクのオフセット分ずれます。行番号は grep -n またはファイルから取得してください。レビュー担当者が引用された行を見つけられなければ、レポートの残りも読まれません。
• ベースラインを確認しないと、既存の失敗を回帰と誤認します。また、通常の pnpm test は毎回何百行もの出力を繰り返します。静かな形式で実行し、最後の行を引用してください。
• 1つの壊れたヘルパーが呼び出し箇所ごとに報告されると、3つの問題として扱われ、ヘルパーが壊れたまま3つのパッチが作られてしまいます。1回だけ報告し、その下に呼び出し箇所を列挙してください。
• REVIEW.md の @path 行は Claude Code Review にとって文字列そのもので、そこではインポートが展開されません。同じようにファイルを読んでください。そうしないと、2つのレポートが食い違い、作者はどちらも信頼しなくなります。

関連スキル

• pr-creator：レビュー後に PR を作成または更新します。コミットと PR の作成はそちらで行います。
• pr-babysitter：CI と受信したレビューコメントを監視し、PR の引き継ぎ形式で投稿します。
• ui-design の監査モード：UI レベルの粗さ、レイアウト、レンダリング品質を対象とします。こちらの Deslop モードが対象とするのはコードレベルの粗さのみです。
• test-audit：リポジトリ全体を対象に、測定可能なカバレッジ目標に向けてテストスイートを整理します。このスキルが対象とするのは、差分で追加または変更されたテストのみです。「テストスイートを整理する」または「テストを20％削減する」場合は、そちらに振り分けてください。

メンテナンスのみ：evals/evals.json には、このスキルを変更する人向けの回帰シナリオと振り分け用プロンプトが含まれています。ユーザーのタスク中に読み込まれることはありません。