find-bugs

このスキルはレポート専用であり、根拠に基づいて実行する必要があります。

譲れないルール：

1. 指摘事項を報告する前に、ブランチの差分全体を読みます。
2. 各指摘事項を周辺コードとフレームワークの動作に照らして検証します。
3. 報告するのは実際の不具合または脆弱性のみとし、スタイルに関する意見は含めません。
4. ワークフローは読み取り専用とします。このスキルの実行中にアプリケーションコードを編集してはいけません。
5. チェックリストのリファレンスを使って体系的に確認しますが、実行のたびにチェックリスト全体を貼り付けてはいけません。

バグを見つける

入力

• $request：確認する領域、脅威モデル、サブシステムのヒントなど、任意のレビュー指針

目標

信頼できるブランチレビューを実施します。レビューでは次のことを行います。

• 実際に変更されたコードを読む
• 関連する攻撃面と不具合が起きうる箇所を特定する
• 報告する前に指摘事項を検証する
• 実際の問題を重大度に応じて優先順位付けする
• 重大な問題が見つからなかった場合は、問題がないことを明確に伝える

ステップ 0：レビュー対象範囲を確定する

このスキルでは、デフォルトでリポジトリ全体ではなく、ブランチの変更をレビューします。

次の点を確認します。

• デフォルトブランチ
• レビュー対象がブランチ全体、コミット範囲、またはユーザーが指定した現在の差分のいずれであるか
• 認証、データ整合性、並行処理、シークレットなど、ユーザーが特定の領域を指定しているか

レビューのベースと比較して変更がない場合は、そこで終了し、その旨を明示します。

成功基準：レビュー対象範囲が明確であり、確認できる差分が存在すること。

ステップ 1：実際の差分と変更されたファイルを読む

次を確認し、レビュー対象を把握します。

• デフォルトブランチをベースとしたブランチの差分
• 変更されたファイルの一覧
• 必要に応じて Read を使った変更ファイルのコンテキスト

ルール：

• --stat だけでなく、実際に変更された行を読みます。
• 差分の出力が大きすぎる場合は、ベースとの差分をファイルごとに読みます。
• ネストされたヘルパー（codemap など）がコードの把握に大きく役立つ場合に限り、Skill を使います。

成功基準：レビューに関係する変更ファイルをすべて、十分なコンテキストを把握できるまで読んでいること。

ステップ 2：攻撃面と不具合が起きうる箇所を特定する

変更されたファイルごとに、関連する箇所を特定します。

• ユーザー入力
• データベースクエリ
• 認証と認可
• セッションまたはトークンの処理
• 外部呼び出し
• 暗号処理またはシークレットの取り扱い
• シリアライズと解析
• ファイルシステムのパスとアップロード
• 並行処理または状態遷移
• エッジケースと境界動作

セキュリティ上のリスクが小さいファイルにもロジックの不具合が含まれる可能性があるため、完全に確認を省略してはいけません。

全体的なレビューマトリクスについては、references/review-checklists.md を読み込みます。

成功基準：変更されたファイルを、実際に関係するリスクに基づいて分類していること。

ステップ 3：対象を絞ったレビューチェックリストを実施する

references/review-checklists.md を使って、次の項目を評価します。

• インジェクション
• XSS と安全でないレンダリング
• 認証と認可
• セッションと CSRF の処理
• 競合状態
• 暗号処理とシークレットの取り扱い
• 情報漏えい
• サービス拒否とリソース枯渇
• ビジネスロジックの正確性
• null 参照、非同期処理の誤り、境界の誤り、戻り値の欠落など、一般的なロジックの不具合

ルール：

• そのパターンがフレームワークによって保護されていると思い込まず、保護が実際にここで適用されるかを確認します。
• ファイルが「単純」に見えるという理由で、チェックリストの項目を省略してはいけません。
• 変更されたコードに重点を置きますが、指摘内容を検証するのに十分な周辺コードも読みます。

成功基準：意味のあるすべてのチェック項目を、実際に変更された箇所に照らして評価していること。

ステップ 4：指摘候補をそれぞれ検証する

問題を報告する前に、次の点を確認します。

• 周辺の関数と呼び出し元のコンテキスト
• ミドルウェア、ヘルパー、ラッパーがすでに問題を緩和していないか
• 既存のテストがその状況をすでにカバーしていないか
• 実際に悪用できるか、または動作に誤りが生じるか

指摘を確信を持って検証できない場合は、報告から除外するか、検証できていない点を明確に示します。

確証の弱い疑いを、指摘事項として誇張してはいけません。

成功基準：報告する問題がすべて誤検知の確認を通過していること。

ステップ 5：分類と優先順位付け

実際の影響に基づいて深刻度を割り当てます。

• Critical
• High
• Medium
• Low

次の順に優先します。

• 悪用可能なセキュリティ上の問題
• 次に、正確性とデータ整合性に関するバグ
• その後、リスクは低くても実際の欠陥に当たる品質上の問題

深刻度の指針を確認するため、references/review-checklists.md を読み込みます。

成功基準：指摘事項が、見つけやすさではなく実際のリスクに基づいて並んでいること。

ステップ 6：根拠を示して報告する

各指摘について、次の内容を報告します。

• File:Line
• 深刻度
• カテゴリ
• 問題の簡潔な説明
• 問題が実在する根拠
• 該当する場合は、悪用経路または障害に至る経路
• 具体的な修正方針

また、次の内容も報告します。

• レビューしたファイル
• チェックリストの確認範囲の概要
• 十分に検証できていない領域

重要な指摘がない場合は、その旨を明示します。

成功基準：別のエンジニアが、問題を一から再調査せずに報告に基づいて対処できること。

ガードレール

• このスキルの一環としてコードを編集しないでください。
• スタイルのみの問題は報告しないでください。
• 網羅的に見せるために指摘事項を捏造しないでください。
• disable-model-invocation を追加しないでください。このスキルは、ユーザーが依頼した際にプロアクティブなレビューに引き続き利用できる状態にしてください。
• paths: を追加しないでください。これは汎用的なワークフロースキルです。
• 詳細なチェックリストはインラインの SKILL.md ではなく、references に置いてください。

References を読み込むタイミング

• references/review-checklists.md セキュリティ、ロジック、深刻度、報告に関する詳細なチェックリストに使用します。

出力仕様

次の内容を報告します。

1. レビューしたファイル
2. 深刻度別の指摘事項
3. 根拠を含む簡潔で詳細な指摘
4. チェックリストの確認範囲と検証上の不足
5. 重要なバグが見つからなかった場合は、その旨を明示したクリーンな結果