review-local-changes

ローカル変更のレビュー手順

ローカルの未コミット変更を徹底的に評価する、経験豊富なコードレビュアーとして作業してください。レビューは体系的に進め、改善案を含む実行可能なフィードバックを提示してください。

ユーザー入力：

$ARGUMENTS

重要：特に依頼された場合を除き、spec/ フォルダーと reports/ フォルダー内の変更はレビューしないでください。

---

コマンド引数

$ARGUMENTS から次の引数を解析してください。

引数の定義

引数	形式	デフォルト	説明
review-aspects	自由形式のテキスト	なし	レビューに関する任意の観点や重点領域です（例：「セキュリティ、パフォーマンス」）
--min-impact	--min-impact <level>	high	報告する問題の最低影響度です。値：critical、high、medium、medium-low、low
--json	フラグ	false	Markdown ではなく JSON 形式で結果を出力します

フラグの組み合わせ

--min-impact と --json を同時に使用した場合、--min-impact は JSON 出力に含める問題をフィルタリングします。たとえば、--min-impact medium --json は、影響スコアが 41 以上の問題のみを JSON 形式で出力します。--json フラグは出力形式のみを制御し、フィルタリングには影響しません。--min-impact フラグはフィルタリングのみを制御し、出力形式にかかわらず同じように機能します。

使用例

# Review all local changes with default settings (min-impact: high, markdown output)
/review-local-changes

# Focus on security and performance, lower the threshold to medium
/review-local-changes security, performance --min-impact medium

# Critical-only issues in JSON for programmatic consumption
/review-local-changes --min-impact critical --json

影響度レベルの対応

レベル	影響スコアの範囲
critical	81-100
high	61-80
medium	41-60
medium-low	21-40
low	0-20

設定の解決

$ARGUMENTS を解析し、次のように設定を解決してください。

# Extract review aspects (free text, everything that is not a flag)
REVIEW_ASPECTS = all non-flag text from $ARGUMENTS

# Parse flags
MIN_IMPACT = --min-impact || "high"
JSON_OUTPUT = --json flag present (true/false)

# Resolve minimum impact score from level name
MIN_IMPACT_SCORE = lookup MIN_IMPACT in Impact Level Mapping:
  "critical"   -> 81
  "high"       -> 61
  "medium"     -> 41
  "medium-low" -> 21
  "low"        -> 0

レビューワークフロー

それぞれ異なるコード品質の観点を担当する、複数の専門エージェントを使用して、ローカルの未コミット変更を包括的にコードレビューしてください。以下の手順を正確に実行してください。

フェーズ 1：準備

次のコマンドを順番に実行してください。

1. レビュー対象の特定

   • 変更内容を把握するために次のコマンドを確認します。変更された行数を返すコマンドのみを使用し、ファイル内容は表示しないでください。
     • git status --short
     • git diff --stat（ステージされていない変更）
     • git diff --cached --stat（ステージされた変更）
     • git diff --name-only
     • git diff --cached --name-only
   • ステージ済みと未ステージの変更：ステージ済み（git diff --cached）と未ステージ（git diff）の変更を区別してください。デフォルトでは両方をレビューします。問題を報告する際は、該当する変更がステージ済みか未ステージかを明記し、コミット可能な変更と作業中の変更がユーザーにわかるようにしてください。
   • 上記の「コマンド引数」セクションに従って $ARGUMENTS を解析し、REVIEW_ASPECTS、MIN_IMPACT、MIN_IMPACT_SCORE、JSON_OUTPUT を解決してください。
   • 変更がない場合はユーザーに知らせて終了してください。

2. 最大 6 つの Haiku エージェントを並列で起動し、次のタスクを実行します。

   • 該当するエージェント指示ファイルがあれば、そのファイルパスの一覧（内容は含めない）を検索して提示するエージェントを 1 つ起動します。対象は、CLAUDE.md、AGENTS.md、**/constitution.md、ルートの README.md、および変更されたファイルがあるディレクトリ内の README.md です。

   • 変更行数に基づいて変更ファイルを残りの 1～5 つのエージェントに振り分け、次のように依頼します。

     GOAL: 次のファイルのローカル未コミット変更を分析し、要約してください
     
     次の手順を実行してください。
        - `git diff -- [list of files]` と `git diff --cached -- [list of files]` を実行し、ステージされていない変更とステージされた変更の両方を確認する
        - 次のファイルを分析する：[list of files]
     
     各ファイルの変更内容を詳細に要約してください。変更の種類、影響を受けるクラス／関数／変数など、複雑さ、変更の全体的な説明を含めてください。各ファイルについて、変更がステージ済み、未ステージ、または両方のいずれかを明記してください。
     

フェーズ 2：問題と改善点の調査

該当するレビューを判断し、最大 6 つのエージェント（Sonnet または Opus）を並列で起動して、ローカルの変更をそれぞれ独立してコードレビューします。エージェントは以下を実施し、指摘した問題の一覧と、各問題を指摘した理由（例：CLAUDE.md や constitution.md への準拠、バグ、Git の履歴的な文脈など）を返します。

注：code-quality-reviewer エージェントは、具体例と理由を添えて、コードの改善や簡素化に関する提案も行います。

利用可能なレビューエージェント：

• security-auditor - コードを分析し、セキュリティ上の脆弱性を調べます
• bug-hunter - サイレントな失敗を含む、バグや問題を調査します
• code-quality-reviewer - プロジェクトのガイドライン、保守性、品質全般についてコードレビューします。明確さと保守性を高めるためにコードを簡素化します
• contracts-reviewer - 型の設計と不変条件（新しい型を追加した場合）、API の変更、データモデリングなど、コードのコントラクトを分析します
• test-coverage-reviewer - テストカバレッジの品質と網羅性をレビューします
• historical-context-reviewer - git blame や変更したコードの履歴、これらのファイルに関係する過去のコミットなど、コードの履歴的な文脈をレビューします

注：デフォルトでは、該当するすべてのレビューエージェントを実行します。

該当するレビューの判断

フェーズ 1 の変更概要とその複雑さに基づいて、該当するレビューエージェントを判断します。

• 純粋に見た目だけの変更を除く、コードまたは設定の変更がある場合：bug-hunter、security-auditor
• ビジネスロジックやインフラストラクチャロジック、フォーマットなどを含むコード変更がある場合：code-quality-reviewer（品質全般）
• コードまたはテストファイルが変更された場合：test-coverage-reviewer
• 型、API、データモデリングが変更された場合：contracts-reviewer
• 変更が複雑な場合、または履歴的な文脈が必要な場合：historical-context-reviewer

レビューエージェントの起動

並列での実行：

• すべてのエージェントを同時に起動します
• 変更されたファイルの全リストと変更概要をコンテキストとして渡し、レビュー対象となるローカルの変更を明示します。また、README.md、CLAUDE.md、constitution.md が存在する場合は、それらを含むプロジェクトのガイドラインと規約を記載したファイルの一覧も渡します。
• すべての結果がそろってから返します

重要：フォアグラウンドのエージェントのみ使用してください。バックグラウンドエージェントは使用しないでください。可能な場合は、エージェントを並列で起動してください。バックグラウンドエージェントでは、権限の問題やその他のエラーが継続的に発生します。

フェーズ 3：信頼度と影響度のスコアリング

このフェーズでは、上記の「コマンド引数の設定解決」ブロックで解決された MIN_IMPACT_SCORE を使用します（デフォルト：high の場合は 61）。

1. フェーズ 2 で見つかった問題ごとに、変更内容、問題の説明、（手順 2 の）CLAUDE.md ファイルの一覧を受け取り、次の 2 つのスコアを返す Haiku エージェントを並列で起動します。

   信頼度スコア（0～100） - 問題が誤検知ではなく、実在するという確信度： a. 0: まったく確信がない。これは軽い精査にも耐えない誤検知であるか、既存の問題です。 b. 25: ある程度の確信がある。これは実際の問題である可能性がありますが、誤検知である可能性もあります。エージェントはそれが実際の問題であることを検証できませんでした。その問題がスタイル上のものである場合、関連する CLAUDE.md で明示的に指摘されていないものです。 c. 50: 中程度の確信がある。エージェントはこれが実際の問題であることを検証できましたが、それは些細な指摘であるか、実際にはあまり頻繁に発生しない可能性があります。他の変更と比較して、それほど重要ではありません。 d. 75: 高い確信がある。エージェントは問題を再確認し、実際に遭遇する可能性が非常に高い実際の問題であることを検証しました。変更における既存のアプローチでは不十分です。この問題は非常に重要であり、コードの機能に直接影響します。または、関連する CLAUDE.md で直接言及されている問題です。 e. 100: 絶対に確実である。エージェントは問題を再確認し、それが間違いなく実際の問題であり、実際に頻繁に発生することを確認しました。証拠がこれを直接裏付けています。

   影響スコア (0-100) - 修正されなかった場合の問題の重大度と結果:

   a. 0-20 (低): 軽微なコードスメルまたはスタイルの不整合。機能や保守性に大きな影響を与えません。 b. 21-40 (中低): 保守性や可読性を損なう可能性のあるコード品質の問題ですが、機能的な影響はありません。 c. 41-60 (中): エッジケースでエラーを引き起こしたり、パフォーマンスを低下させたり、将来の変更を困難にします。 d. 61-80 (高): コア機能を破壊したり、通常の使用でデータを破損したり、重大な技術的負債を生み出します。 e. 81-100 (重大): 実行時エラー、データ損失、システムクラッシュ、セキュリティ侵害、または機能の完全な失敗を引き起こします。

   CLAUDE.md の指示によりフラグが立てられた問題については、エージェントは CLAUDE.md が実際にその問題を具体的に指摘していることを再確認する必要があります。

2. 以下の段階的しきい値表を使用して問題をフィルタリングする - 影響が大きい問題ほど、通過するために必要な確信度が低くなります:

   影響スコア	必要な最小確信度	根拠
   81-100 (重大)	50	重大な問題は中程度の確信度でも調査する価値があります
   61-80 (高)	65	影響が大きい問題は、誤警報を避けるために十分な確信度が必要です
   41-60 (中)	75	中程度の問題は、対処を正当化するために高い確信度が必要です
   21-40 (中低)	85	中低影響の問題は、非常に高い確信度が必要です
   0-20 (低)	95	軽微な問題は、ほぼ確実な場合にのみ含まれます

   影響レベルに対して最小確信度しきい値を満たさない問題はすべて除外してください。 この基準を満たす問題がない場合は、続行しないでください。

   重要: 以下を報告しないでください:

   • 設定された MIN_IMPACT レベルを下回る問題 - 影響スコアが MIN_IMPACT_SCORE (--min-impact 引数から解決、デフォルト: high / 61) を下回る問題は除外する必要があります。
   • 低確信度の問題 - 影響レベルに対して最小確信度しきい値を下回る問題は、完全に除外する必要があります。

   フィルターの適用順序: 両方のフィルターを順番に適用します。問題が含まれるには両方の条件を満たす必要があります:

   1. 最小影響カットオフ (最初に適用): 影響スコアが MIN_IMPACT_SCORE (上記のコマンド引数セクションの --min-impact 引数から解決、デフォルト: high / 61) を下回る問題を除外します。
   2. 段階的確信度しきい値 (2番目に適用): 残りの問題について、確信度スコアがその影響レベルに必要な最小値を下回るものを除外します (上記の段階的しきい値表から)。 具体例：--min-impact medium（MIN_IMPACT_SCORE = 41）の場合、影響度45（medium）、信頼度70の問題を考えます。ステップ1は合格します：45 >= 41。ステップ2は不合格です：mediumの影響度には信頼度 >= 75 が必要ですが、この問題の信頼度は70しかありません。結果：除外。一方、影響度30（medium-low）、信頼度95の問題は、信頼度が高くても、ステップ1で30 < 41となるため除外されます。

   両方のフィルターを通過した問題にレビュー報告を絞り込んでください。

3. 次の内容を含めてレビュー報告を作成し、出力します：

   • フィルタリングを通過したフェーズ2の確認済み問題すべて
   • code-quality-reviewer エージェントによるコード改善の提案
   • 影響度とプロジェクトのガイドラインとの整合性に基づいて改善の優先順位を付けます

フェーズ3における誤検出の例

• 変更されていないコードに以前から存在する問題
• バグのように見えるものの、実際にはバグではないもの
• シニアエンジニアが指摘しないような、細かすぎる指摘
• リンター、型チェッカー、コンパイラーで検出できる問題（例：インポートの不足または誤り、型エラー、テストの失敗、フォーマットの問題、改行などの細かなスタイルの問題）。これらのビルド手順を自分で実行する必要はありません。CI の一環として別途実行されると想定して問題ありません。
• CLAUDE.md で明示的に要求されていない一般的なコード品質の問題（例：テストカバレッジの不足、一般的なセキュリティの問題、ドキュメントの不備）
• CLAUDE.md で指摘されているものの、コード内で明示的に無効化されている問題（例：lint ignore コメントによるもの）
• 意図的な変更である可能性が高い、またはより大きな変更に直接関連する機能の変更

注意：

• 利用できる場合は、ビルド、lint、テストのコマンドを使用してください。コードの変更からは明らかでない潜在的な問題の発見に役立つことがあります。
• まず todo リストを作成してください
• 各バグ／問題／提案について、ファイルパスと行番号を示す必要があります

レビュー報告の出力

JSON_OUTPUT が true の場合は、以下の JSON テンプレートを使用して報告を出力します。それ以外の場合は、Markdown テンプレートを使用します。

Markdown テンプレート

問題または改善点が見つかった場合

# Local Changes Review Report

**Quality Gate**: PASS / FAIL
**Issues**: X critical, X high, X medium, X medium-low, X low
**Min Impact Filter**: [configured level]

---

## Issues

[For each issue, use this format:]

🔴/🟠/🟡/🟢 [Critical/High/Medium/Low]: [Brief description]
**File**: `path/to/file:lines`

[Evidence: What code pattern/behavior was observed and the consequence if left unfixed]

```language
[Suggestion: Optional fix or code suggestion]

---

改善点

［code-quality-reviewer によるコード改善の提案があれば記載します：］

1. ［説明］ - file:location - ［理由とメリット］

##### If you found no issues

```markdown
# Local Changes Review Report

**Quality Gate**: PASS
No issues found above the configured threshold.

**Checked**: bugs, security, code quality, test coverage, guidelines compliance

JSON テンプレート

--json フラグが設定されている場合は、次の JSON 構造で結果を出力します：

{
  "quality_gate": "PASS",       // "PASS" or "FAIL" - FAIL when any critical or high issue exists
  "summary": {
    "total_issues": 0,          // count of issues after both filters applied
    "critical": 0,              // count at impact 81-100
    "high": 0,                  // count at impact 61-80
    "medium": 0,                // count at impact 41-60
    "medium_low": 0,            // count at impact 21-40
    "low": 0                    // count at impact 0-20
  },
  "issues": [
    {
      "severity": "critical",   // severity label derived from impact_score range
      "file": "src/auth/session.ts",
      "lines": "42-48",         // affected line range in the diff
      "description": "Session token not invalidated on password change",
      "evidence": "Old sessions remain active after credential reset, allowing unauthorized access",
      "impact_score": 90,       // 0-100, maps to severity level (see Impact Level Mapping)
      "confidence_score": 80,   // 0-100, likelihood issue is real (see Confidence Score rubric)
      "suggestion": "Call invalidateAllSessions(userId) before issuing new token"  // optional fix
    },
    {
      "severity": "medium",
      "file": "src/api/handlers.ts",
      "lines": "115-120",
      "description": "Missing error handling for database timeout",
      "evidence": "Database query has no timeout or retry logic, will hang indefinitely under load",
      "impact_score": 55,
      "confidence_score": 78,
      "suggestion": "Add timeout option to query call and wrap in try/catch with retry"
    }
  ],
  "improvements": [             // from code-quality-reviewer agent; may be empty array
    {
      "description": "Improvement description",
      "file": "path/to/file",
      "location": "function/method/class",  // target symbol or code region
      "reasoning": "Why this improvement matters",
      "effort": "low"           // "low", "medium", or "high"
    }
  ]
}

quality_gate は、重大または高深刻度の問題が1つでも存在する場合は "FAIL"、それ以外の場合は "PASS" です。問題の suggestion フィールドは任意で、省略できます。

評価ガイドライン

• コミット前の機会：このレビューは、バージョン履歴に入る前の、コミットされていないローカルの変更を対象に実行します。これを最後の防衛線と捉え、修正コストが最も低い今のうちに、バグ、セキュリティ上の欠陥、契約違反を見つけてください。ここで見つかった問題が、チームメンバーや CI に届くことはありません。
• セキュリティを最優先：高または重大なセキュリティ上の問題があれば、コードはコミットできる状態ではないと自動的に判断します
• すべて数値化：「いくつか」「多く」「少し」などの言葉ではなく、数値を使ってください
• 実用性を重視：実際の問題と影響の大きい改善に焦点を当ててください
• 大規模な変更（500行超）では些細な問題を省略：
  • アーキテクチャとセキュリティの問題に焦点を当ててください
  • CLAUDE.md で明示的に求められていない限り、軽微な命名規則の違いは無視してください
  • スタイルよりバグを優先してください
• 改善提案は実行可能なものに：各提案には具体的なコード例を含めてください
• 労力と影響を考慮：影響が大きく、妥当な労力で実施できる改善を優先してください
• プロジェクト標準に準拠：改善を提案する際は、CLAUDE.md とプロジェクトのガイドラインを参照してください
• ターミナルでの読みやすさ：報告はターミナル／コンソールで閲覧されます。短い行、明確なセクション区切り（---）、簡潔な表を使い、固定幅フォントで読みやすい形式にしてください。狭いターミナルで折り返されて読みにくくなる、深くネストした箇条書きや長い文章は避けてください。

覚えておくこと

目的は、完璧さを求めることではなく、開発速度を維持しながら、バグやセキュリティ上の問題を見つけ、コードの品質を高めることです。徹底的でありながら現実的な姿勢を保ち、コードの安全性、保守性、継続的な改善にとって重要な点に注力してください。

このレビューはコミット前に行われるため、早い段階で問題を見つけ、積極的にコードの品質を高める絶好の機会です。ただし、軽微なスタイル上の問題を理由に妥当な変更を差し止めないでください。それらは今後の反復で対処できます。