fix-review

修正レビュー

コミットがセキュリティ上の指摘事項に対処し、バグを新たに持ち込んでいないことを確認する差分分析です。

使用する場面

• セキュリティ監査レポートと修正ブランチを比較してレビューする
• 修正コミットが指摘事項に実際に対処しているか検証する
• 特定の指摘事項（TOB-XXX 形式）が修正されたか確認する
• バグを持ち込むパターンがないか、コミット範囲を分析する
• コード変更を監査の推奨事項と照合する

使用しない場面

• 初回のセキュリティ監査（audit-context-building または differential-review を使用してください）
• 特定のベースラインや指摘事項セットのないコードレビュー
• 過去の監査がない状態での新規開発
• ドキュメントのみの変更

---

よくある合理化（省略しないでください）

合理化	誤りである理由	必須の対応
「コミットメッセージに TOB-XXX を修正すると書いてある」	メッセージは事実と異なる場合があります。真実を示すのはコードです	実際のコード変更が指摘事項に対処していることを検証する
「小さな修正だから、新たなバグは起こりえない」	小さな変更が大きなバグを引き起こすことがあります	アンチパターンがないか、すべての変更を分析する
「重要な指摘事項だけ確認すればよい」	すべての指摘事項が重要です	すべての指摘事項を体系的に確認する
「テストは通っている」	テストでは修正箇所がカバーされていない可能性があります	テストの結果だけでなく、修正ロジックを検証する
「同じ開発者だから、コードを理解している」	慣れは見落としを生みます	変更を一つずつ新たに分析する

---

クイックリファレンス

入力要件

入力	必須	形式
ソースコミット	はい	Git コミットハッシュまたは参照（修正前のベースライン）
対象コミット	はい	分析する1つ以上のコミットハッシュ
セキュリティレポート	いいえ	ローカルパス、URL、または Google Drive のリンク

指摘事項のステータス

ステータス	意味
FIXED	コード変更が指摘事項に直接対処しています
PARTIALLY_FIXED	一部には対処していますが、未対応の箇所が残っています
NOT_ADDRESSED	関連する変更が見つかりません
CANNOT_DETERMINE	検証に必要なコンテキストが不足しています

---

ワークフロー

フェーズ 1：入力の収集

ユーザーから必要な入力を収集します。

Source commit:  [hash/ref before fixes]
Target commit:  [hash/ref to analyze]
Report:         [optional: path, URL, or "none"]

ユーザーが対象コミットを複数指定した場合は、同じソースを使ってそれぞれ個別に処理します。

フェーズ 2：レポートの取得

セキュリティレポートが提供された場合は、形式に応じて取得します。

ローカルファイル（PDF、MD、JSON、HTML）： Read ツールを使ってファイルを直接読み取ります。Claude は PDF をネイティブに処理します。

URL： WebFetch ツールを使ってウェブコンテンツを取得します。

取得に失敗する Google Drive の URL： gdrive CLI を使った Google Drive のフォールバック処理については、references/report-parsing.md を参照してください。

フェーズ 3：指摘事項の抽出

レポートを解析し、指摘事項を抽出します。

Trail of Bits 形式：

• 「Detailed Findings」セクションを探します
• 次のパターンに一致する指摘事項を抽出します：TOB-[A-Z]+-[0-9]+
• ID、タイトル、重大度、説明、影響を受けるファイルを取得します

その他の形式：

• 番号付きの指摘事項（Finding 1、Finding 2）
• 重大度別のセクション（Critical、High、Medium、Low）
• findings 配列を含む JSON

詳細な解析方法については、references/report-parsing.md を参照してください。

フェーズ 4：コミットの分析

各対象コミットについて、コミット範囲を分析します。

# Get commit list from source to target
git log <source>..<target> --oneline

# Get full diff
git diff <source>..<target>

# Get changed files
git diff <source>..<target> --name-only

範囲内の各コミットについて：

1. 差分を確認し、バグを持ち込むパターンがないか調べます
2. セキュリティ上のアンチパターンを確認します（references/bug-detection.md を参照）
3. 変更を関連する指摘事項に対応付けます

フェーズ 5：指摘事項の検証

レポート内の指摘事項ごとに、次の手順を実施します。

1. 関連するコミットを特定する - 次の情報を照合します。

   • 指摘事項に記載されたファイルパス
   • 指摘事項の説明に記載された関数名／変数名
   • 指摘 ID に言及しているコミットメッセージ

2. 修正を検証する - 次の点を確認します。

   • 根本原因に対処していること（症状だけに対処していないこと）
   • 修正がレポートの推奨事項に沿っていること
   • 新たな脆弱性が持ち込まれていないこと

3. ステータスを割り当てる - 証拠に基づいて判断します。

   • FIXED：指摘事項に対処する明確なコード変更がある
   • PARTIALLY_FIXED：一部の問題は修正されているが、未解決の問題もある
   • NOT_ADDRESSED：関連する変更がない
   • CANNOT_DETERMINE：さらにコンテキストが必要

4. 証拠を記録する - 指摘事項ごとに次の情報を記載します。

   • 対処したコミットハッシュ
   • 具体的なファイルと行の変更
   • 修正によって根本原因にどう対処したか

詳細な照合方法については、references/finding-matching.md を参照してください。

フェーズ 6：出力の生成

次の 2 つの出力を生成します。

1. レポートファイル（FIX_REVIEW_REPORT.md）：

# Fix Review Report

**Source:** <commit>
**Target:** <commit>
**Report:** <path or "none">
**Date:** <date>

## Executive Summary

[Brief overview: X findings reviewed, Y fixed, Z concerns]

## Finding Status

| ID | Title | Severity | Status | Evidence |
|----|-------|----------|--------|----------|
| TOB-XXX-1 | Finding title | High | FIXED | abc123 |
| TOB-XXX-2 | Another finding | Medium | NOT_ADDRESSED | - |

## Bug Introduction Concerns

[Any potential bugs or regressions detected in the changes]

## Per-Commit Analysis

### Commit abc123: "Fix reentrancy in withdraw()"

**Files changed:** contracts/Vault.sol
**Findings addressed:** TOB-XXX-1
**Concerns:** None

[Detailed analysis]

## Recommendations

[Any follow-up actions needed]

2. 会話の概要：

会話内で簡潔な概要を提示します。

• 指摘事項の合計：X
• 修正済み：Y
• 未対処：Z
• 懸念事項：[バグを持ち込むリスクがあれば記載]

---

バグの検出

コミットを分析し、セキュリティ上のアンチパターンを検出します。次のようなパターンに注意してください。

• アクセス制御の弱体化（修飾子の削除）
• 検証の削除（require/assert の削除）
• エラー処理の縮小（try/catch の削除）
• 外部呼び出しの順序変更（呼び出し後に状態を変更）
• 整数演算の変更（SafeMath の削除）
• 暗号処理の弱体化

包括的な検出パターンと例については、references/bug-detection.md を参照してください。

---

他のスキルとの連携

differential-review： 変更の初期セキュリティレビュー（監査の前）

issue-writer： 指摘事項を正式な監査レポートの形式に整える

audit-context-building： 複雑な修正を分析する際に詳細なコンテキストを得る

---

効果的なレビューのヒント

実施すること：

• コミットメッセージだけでなく、実際のコード変更を検証する
• 修正が症状ではなく根本原因に対処していることを確認する
• 隣接するコードへの意図しない副作用を探す
• 相互に影響する可能性のある複数の指摘事項を相互参照する
• ステータスを割り当てるたびに証拠を記録する

避けること：

• 修正の証拠としてコミットメッセージを信頼する
• 軽微に見えるという理由で指摘事項を見送る
• テストに合格すれば修正も正しいと想定する
• 「修正」の範囲外の変更を無視する
• 明確な証拠なしに FIXED と判定する

---

参考ファイル

詳細なガイダンスについては、次を参照してください。

• references/finding-matching.md - コミットと指摘事項を照合する方法
• references/bug-detection.md - アンチパターンの包括的な検出方法
• references/report-parsing.md - さまざまなレポート形式の解析と Google Drive のフォールバック