code-review

コードレビュー

コードの品質をレビューし、改善するためのスキルです。意図に応じてモードを選択するか、mode: パラメーターを明示的に渡してください。各モードは references/ にある、独立して完結したワークフローです。必要なモードだけを読み込み、エージェントのコンテキスト予算を節約してください。

モード

モード	ユーザーが求めていること	読み取り／書き込み	出力	ワークフロー
review（デフォルト）	差分／PR のバグ、セキュリティ上の欠陥、品質上の問題を見つける	読み取り専用	優先順位付きの指摘レポート	references/review-mode.md
perf	コードを高速化する — ボトルネック、リーク、アルゴリズム上の無駄への対処	読み取り専用	パフォーマンスに関する指摘レポート	references/perf-mode.md
clean	bbv Clean Code チートシートに照らして、可読性／規約への準拠を監査する	読み取り専用	CLEAN_CODE_AUDIT.md	references/clean-mode.md
cleanup	AI 由来の粗雑なコード、不要なコード、重複、不要物を実際にリファクタリングで取り除く	コードを書き込みます	変更済みのソースファイル	references/cleanup-mode.md

モードの選択

1. 明示指定を優先します。 リクエストに mode:review|perf|clean|cleanup（または --mode <name>）が含まれる場合は、そのモードを使用してください。
2. それ以外はリクエストから推測します。 一致したフレーズが別の一致フレーズの中に含まれる場合は、長いほうだけを採用します。そのため、"clean code review" は clean のフレーズにのみ一致し、review のフレーズには一致しません。重複しないフレーズは、（手順 3 に記載のとおり）長さにかかわらず、すべて一致として扱います。
   • "review"、"find bugs"、"security"、"is this correct"、"look for vulnerabilities" → review
   • "slow"、"faster"、"optimize"、"bottleneck"、"memory leak"、"performance" → perf
   • "clean code audit"（または "clean-code audit"）、"clean code review"、"check this against clean code" → clean （ユーザーが明示的に指定した場合のみ — 単に "readability" や "audit against standards" を求めている場合は曖昧です。手順 3 を使用してください）
   • "remove slop"、"clean up the codebase"、"refactor out cruft / dead code / duplication" → cleanup
3. 一致するものがない場合、または複数のモードのフレーズが含まれる場合は、どのモードを使うか尋ねてください。 4 つの選択肢を示してください。たとえば、"review and optimize" は review と perf の両方に一致するため、確認を求めます。リクエストに review のフレーズが含まれ、ほかのモードのフレーズが含まれない場合に限り、確認せず review を使用してください。

安全性：cleanup はコードを書き換えます。他の 3 つは書き換えません

review、perf、clean はソース読み取り専用です。ソースファイルを変更せずに分析と報告を行います。review と perf は、各モードで指定されたレポート成果物のみを書き込む場合があります（review は CODE_REVIEW.md、perf はレスポンス内でレポートを返します）。review／perf の分析中は、それ以外の方法でインデックス、参照、スタッシュ、ブランチ、ワークツリー、リモートの状態を変更してはいけません。clean には独自のレポート書き込みおよび同期に関する契約があります。cleanup はファイルを変更します。したがって、次のルールに従ってください。

• 弱い推測で cleanup に入ってはいけません。 ユーザーがコードベースのリファクタリング／クリーンアップを明示的に依頼した場合（または mode:cleanup を指定した場合）に限り実行してください。単に「コードをレビューして」と依頼された場合、ファイルを書き換えてはいけません。読み取り専用モードを維持してください。
• review と perf の分析では、リモートの最新状態を確認したと主張せず、git rev-parse HEAD、git status、ローカルの追跡状況に関する観察結果を記録します。fetch、stash、pull、rebase、checkout／switch、ブランチやワークツリーの作成／削除、ソースコードの修正適用は行いません。別途承認された変更ワークフローでは、独自の最新状態確認とスタッシュ優先の同期契約に従います。
• cleanup で最初に書き込む前に確認を求め、そのモード独自の実行条件に従ってください。

編集前のリポジトリ同期（必須）

clean（CLEAN_CODE_AUDIT.md に書き込みます）と cleanup（ソースに書き込みます）のみに適用されます。review と perf では同期しません（「安全性」セクションを参照）。どちらのモードでも、最初の書き込みを行う前に次の手順を実行します。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"

• clean で作業ツリーに変更がある場合は、先にスタッシュしてから同期し、その後スタッシュを適用します。
• cleanup で作業ツリーに変更がある場合は、停止して、先にコミットするかスタッシュするようユーザーに依頼します。
• origin がない場合、またはプルやスタッシュの適用で競合が発生した場合は、停止してユーザーに確認します。ファイルには何も書き込みません。
• 対象が git リポジトリでない場合、clean は同期をスキップし、その旨をレポートに記載します。

復旧コマンドを含む手順の全容は、references/clean-mode.md と references/cleanup-mode.md に記載されています。

モードのワークフローを実行する

選択したモードのリファレンスファイルを読み、その手順を正確に実行します。各モードが使用する補助ファイルは、すでにこのスキルと同じ場所にあります。

• review → references/review-mode.md — エージェント：agents/reviewer.md、agents/file-reviewer.md、agents/report-assembler.md、参照ファイル：references/subagent-architecture.md、references/code-smells.md
• perf → references/perf-mode.md — 参照ファイル：references/language-checks.md
• clean → references/clean-mode.md — 参照ファイル：references/clean-code-checklist.md、references/tdd-checklist.md、references/html-report-guide.md、references/report-template.html
• cleanup → references/cleanup-mode.md — agents/ 内の8つのコード整理エージェント（deduplicator.md、type-consolidator.md、unused-code-killer.md、circular-dep-untangler.md、weak-type-strengthener.md、defensive-programming-remover.md、legacy-code-remover.md、slop-comment-cleaner.md）

環境の確認

Agent ツールを利用できる場合、サブエージェントを使うモード（review、cleanup）では、ワークフローに従ってサブエージェントを起動します。新しいコンテキストでの検証と並行作業を行います。利用できない場合（例：Claude.ai）は、各モードのフェーズをインラインで実行します（厳密さはやや劣りますが、機能します）。

モードの連結

モードは組み合わせて使用できます。一般的な流れは、clean（監査 → CLEAN_CODE_AUDIT.md）の後に cleanup（リファクタリングを適用）を実行する方法です。または、修正前に問題を見つけるために review/perf を実行します。モードは一度に1つずつ実行してください。コードを書き込む cleanup モードに切り替える前に、ユーザーに確認します。

前提条件

• 対象の差分、PR、ファイルセット、またはリポジトリが指定されていない場合は、開始前に対象範囲を尋ねます。
• 選択したモードで指定されているリファレンスファイルまたはエージェントファイルが見つからない場合は、停止し、見つからないパスを提示します。
• clean または cleanup では、そのモードの同期、バックアップ、ドライラン、確認、ロールバックの手順を順番どおりに実行します。同期または安全性の確認に失敗した場合は、最初の書き込みを行う前に停止します。

受け入れ基準

選択したモード固有の受け入れ基準に照らして実行ごとに検証し、その後、次のルーター基準をすべて満たしていることを確認します。

• モードが1つだけ選択され、その参照ワークフローが最初から最後まで実行されています。
• 読み取り専用モードではソースファイルが変更されていません。該当する場合は、パスを指定した git diff で確認します。
• すべての指摘に具体的な根拠が示され、期待される出力アーティファクトまたはレポートが作成されています。
• 選択したモードで必須のテストまたは検証コマンドが、期待される結果で完了しています。
• エッジケース、制約、スキップしたファイル、サブエージェントの適用範囲が縮小した場合は、その旨が開示されています。

最終回答が読者にとって役立つ内容になっていることも確認します。

• 結果が見つけやすい： Mode: の次の1行目に結果と PASS、PARTIAL、FAIL のいずれかが記載されています。
• 事実と前提が分けられている： 検証済みの主張には実行したチェックが明記され、推測、スキップした範囲、未テストの動作は Uncertainty の下に記載されています。
• 主張の根拠を追跡できる： 各指摘に file:line、コマンド出力、またはレポートのセクションが示されています。中間ステップの成功だけでは、実行全体の成功とはみなしません。
• 次の判断が明確： Decision に必要な承認（例：cleanup の開始）が記載されているか、「承認は不要」と明記され、残っているユーザーの作業も列挙されています。

エージェントによる調査では、人が出力を理解したことを確認できません。人からのフィードバックがなかった場合は、人による理解は未確認と報告してください。これを失敗または成功として扱わないでください。

期待される出力

各モードの最終回答には、次の5項目をこの順序で記載します。各項目は1～2行に収め、詳細はモードのレポートアーティファクトに記載します。

Mode: review
Result: PARTIAL — 1 critical, 2 major, 0 minor findings; reviewer pass incomplete for 3 files
Evidence: CODE_REVIEW.md written; reviewer agent validated 41/44 files; `git diff --stat -- src/` empty
Uncertainty: 3 generated files skipped (listed in CODE_REVIEW.md); no tests were run
Decision: No approval needed. To apply fixes, ask for a separate `cleanup` run.

ステップ完了レポート

ルーティング後と、選択したワークフローの実行後に、簡潔なレポートを出力します。

◆ Code Review ([mode])
  Mode selection:      √ pass
  Workflow criteria:   √ pass
  Output verified:     √ pass
  Safety boundary:     √ pass
  Result:              PASS | FAIL | PARTIAL

未達成のチェックには × fail — reason を使用します。選択したモードの受け入れ基準、期待される出力、必須テスト、安全策のいずれかが未解決のまま、PASS と報告してはいけません。

エッジケース

• 不明な mode: 値 → 拒否し、有効な4つのモードを列挙します。
• 複数モードにまたがる意図 → どのモードを先に実行するか尋ねます。ワークフローを暗黙に統合してはいけません。
• 対象が指定されていない、またはファイルにアクセスできない → 推測せずに停止し、具体的な範囲を確認します。
• エージェントツールが利用できない → 選択した参照のインラインフォールバックを使用し、適用範囲が縮小したことを開示します。
• 読み取り専用モードの実行中に編集が求められた → レポートを完成させてから、別途 cleanup を実行する前に明示的な承認を求めます。