code-review

Name: code-review
Author: iuliandita

github.com/iulianditaテスト・品質1058 回インストール1 日前に更新

リポジトリ

code-review について

code-review は、複数の言語やインフラ設定を対象とする、正確性重視のコードレビュー用スキルです。マージやリリース前の確認に向き、スタイルやセキュリティではなく、根拠のある不具合を重視します。

主な機能

01ロジックと境界値を確認
02エラー経路と契約を追跡
03複数言語のコードをレビュー
04確信度に基づき指摘を選別
05根拠と具体的な失敗例を要求

活用シーン

01マージ前の変更内容の確認
02静的ツールが見逃すロジック不具合の調査
03リリース前の重要なコード経路の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill code-review

インストール後、Claude Code で/code-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

ai-age-patterns.md

cicd-pipelines.md

databases.md

go.md

iac.md

java.md

output-contract.md

python.md

report-format.md

shell.md

typescript.md

universal-patterns.md

詳細

コードレビュー：正確性の徹底監査

実際に問題を引き起こすバグを見つけます。スタイルや雑なコードではなく、本番環境で障害につながる正確性、信頼性、ロジックのエラーを対象とします。

このスキルは、code-simplification（コード品質／スタイル）および security-audit（脆弱性／OWASP）を補完します。これらのスキルが「コードはクリーンか？」「コードは安全か？」を確認するのに対し、このスキルは「コードは実際に動作するか？」を確認します。

対象：TypeScript/JavaScript、Python、Go、Java、Bash/Shell、および Infrastructure as Code（Terraform、Ansible、Helm、Kubernetes、Docker/Compose、Proxmox/LXC）。共通のパターンはすべての言語に適用され、言語固有のセクションでは対象を絞った確認項目を追加します。

使用する場面

最近の変更について、バグ、リグレッション、エッジケース、脆弱な前提をレビューするとき
マージまたはリリースの前にコードの妥当性を確認するとき
静的解析ツールでは見つからない可能性のあるロジックエラーを探すとき
スタイルやセキュリティよりも正確性を重視してレビューするとき

3つの質問

すべての指摘は、次のいずれかに答える必要があります。

クラッシュするか？ - null 参照、未処理エラー、リソース枯渇、インポート漏れ
誤った動作をするか？ - ロジックエラー、境界値のずれ、誤った比較、ケース漏れ
後で問題が起きるか？ - 競合状態、暗黙の順序依存、脆弱な前提、API 契約の乖離

使用しない場面

スタイル、冗長さ、機械生成コードの品質に関する問題 - code-simplification を使用
悪用可能な脆弱性、認証の不備、シークレットのスキャン - security-audit を使用
パイプライン設定のレビュー、パイプラインアーキテクチャ、ランナーの動作、キャッシュ、デプロイジョブのバグ - ci-cd を使用
セッション終了時のドキュメント整理や指示ファイルのクリーンアップ - update-docs を使用

AI のセルフチェック

確信度が 80% 以上の指摘を報告する前に、次の項目を確認してください。

ワークフロー

ステップ 1：レビューの範囲を決める

コンテキストに基づくデフォルトの範囲：

このセッションでコードを書いた直後に呼び出された場合 → セルフチェック（直前に書いたコードをレビューする）
未コミットの変更がある場合（git diff --name-only）→ 最近の変更
ユーザーがファイル／ディレクトリ／コミットを指定した場合 → 対象を絞ったレビュー
ユーザーがコードベース全体を依頼した場合 → コードベース全体のレビュー。「大規模なコードベースでの優先順位付け」に従って優先順位を付け、カテゴリ別に報告する
それ以外の場合 → ユーザーに確認する

大規模な差分（500 行超）： ファイルごとに分割します。各ファイルを周辺のコンテキストとともにレビューした後、ファイルをまたいで統合上の問題（境界をまたぐ型の不一致、一貫性のないエラー処理、呼び出しチェーンの破損）を探します。大規模な差分はコードの臭いでもあるため、所見に記載します。

ステップ 2：プロジェクトのコンテキストを把握する

コードをレビューする前に、コンテキストを把握します。

プロジェクトの指示ファイル（AGENTS.md など）があれば読みます。プロジェクトの規約、パターン、既知の注意点を確認します
プロジェクトの言語／フレームワークのバージョンを確認します（package.json、pyproject.toml、go.mod など）
アーキテクチャを把握します。モノリス、マイクロサービス、CLI ツール、ライブラリのどれでしょうか？
独自のエラー処理パターン、ロギング規約、テスト要件を確認します

こうしたコンテキストにより、誤検知を防げます。React アプリでは誤りとなるパターンが、Node CLI ツールでは正しい場合もあります。

ステップ 3：まず機械的なチェックを実行する（利用可能で、実用的な場合）

手動レビューの前に、明らかな問題を取り除くため、標準的なツールを実行します。ただし、実行するのが妥当な場合に限ります。

TypeScript：tsc --noEmit／eslint（tsconfig.json／.eslintrc* がない場合、またはプロジェクトに TypeScript ファイルが 500 個以上あり、時間がかかりすぎる場合はスキップ）
Python：ruff check／mypy（pyproject.toml／ruff.toml／mypy.ini がない場合はスキップ）
Shell：shellcheck（高速なので、インストールされていれば常に実行する価値があります）
Terraform：terraform validate（terraform init がまだ実行されていない場合はスキップ。validate には初期化済みのプロバイダーが必要です）
Ansible：ansible-lint（.ansible-lint 設定がなく、プロジェクトが主に Ansible で構成されていない場合はスキップ）

ツールをスキップする場合：

プロジェクトに設定ファイルがない場合（tsconfig.json、pyproject.toml などがない）
小規模な差分（5 ファイル未満）をレビューする場合。3 ファイルの変更に対してプロジェクト全体のリンティングを行うのは無駄です
ユーザーが完全な監査ではなく、簡単なレビューだけを求めている場合

ツールがインストールされていない場合（command -v <tool> で確認）：黙ってスキップしないでください。不足しているツールと、パッケージ名およびインストールコマンドを一度ユーザーに伝えます（例：「shellcheck がインストールされていません。pacman -S shellcheck でのインストールをご検討ください」）。その後、そのツールを使わずにレビューを続けます。

リンターは、構文、インポート、既知のアンチパターンを機械的に検出します。このスキルでは、自動ツールが見逃す、ロジックエラー、エッジケース、誤った前提、意図を理解しないと見つけにくい微妙なバグに焦点を当てます。リンターの出力に時間やトークンを費やさず、実際のレビューに進みます。

ステップ 4：4 つの観点からレビューする

4 つの観点でコードを確認します。これらは順番に行うレビューではなく、読み進めながら評価するための観点です。優先順位を反映した順になっています。まず意図を理解することが重要です。他のすべてはそれに依存するためです。

観点 1：意図を理解する コードを読み、何をするためのものかを理解します。差分をレビューする場合は、周辺のコンテキストも確認します。コミットメッセージ、PR の説明、コメントに記載された意図も確認します。「正しい」状態が分からなければ、バグは見つけられません。

観点 2：ロジックの経路をたどる すべてのコードパスを追います。各分岐、ループ、条件について、次を確認します。

正常系では何が起こりますか？
各エラー経路では何が起こりますか？
境界値（空、ゼロ、最大値、null、負数）では何が起こりますか？
すべてのケースが処理されていますか？（switch/match の網羅性、if/else の完全性）

境界値分析には、特に注意を払う必要があります。関数の契約と実際の呼び出し元に照らして、page=1、page=0、page=-1、ページサイズが 0、最終ページ、算術オーバーフローを追跡します。無効な入力が失敗する操作に到達する、または誤った結果を返す場合は、ガードの欠落を報告してください。残りの SQL 行数を超える LIMIT は通常有効です。一方、配列の末尾を超えるスライスはパニックを起こすことがあります。下流で除算が起こると決めつけたり、数値の境界値をすべてバグと見なしたりしないでください。他の指摘と同じ証拠基準と確信度の基準を適用してください。

観点 3：契約と境界を確認する コンポーネント間のすべてのインターフェースを調べます。

関数シグネチャ：呼び出し元は適切な型や形式の値を渡していますか？
API の境界：入力は使用前に検証されていますか？
状態遷移：事前条件は確認されていますか？
エラーの伝播：エラーには十分なコンテキストが含まれていますか？
リソースのライフサイクル：取得と解放は対称的に行われていますか？
下流への影響：エクスポートされた関数、インターフェース、API エンドポイントへの変更をレビューする場合は、すべての呼び出し元や利用箇所を grep で検索します。設定や環境変数の変更では、変更したキーを参照しているすべてのファイルを確認します。あるファイルのブール値の切り替えが、12 のモジュールにわたる機能フラグのロジックを壊すこともあります。

観点 4：規約への準拠 スタイルではなく、コードが動作するかどうかに影響するプロジェクト固有の正確性ルールを確認します（スタイルはコードの簡素化で扱います）。

エラー処理、トランザクション、API パターンに関するプロジェクトの指示ファイルのルール
周辺コードにおけるエラー処理や状態管理との一貫性
正確性に影響するフレームワークの慣用表現（スタイルだけのものは除く）
重要な経路に必要なテストカバレッジ

ステップ 5：各指摘事項を評価する

潜在的な問題ごとに、確信度を 0〜100 で評価します。

スコア	意味	対応
0	誤検知です。精査に耐えません。	破棄
25	実際の問題かもしれません。意図的なもの、または状況次第の可能性もあります。	破棄
50	根拠がまちまちで、問題は立証されていません。	破棄
75	実際の問題である可能性は非常に高いものの、重要な前提が残っています。	境界線上
80+	具体的な証拠と周辺の状況により裏付けられています。深刻度は別途評価します。	報告
100	疑いの余地がありません。コードは明らかに誤っています。根拠も明白です。	報告

スコアが 80 以上の指摘事項のみ報告してください。 件数より品質を重視します。実際のバグが 3 件ある報告のほうが、可能性にすぎない指摘が 20 件ある報告より優れています。

セルフレビュー時の例外： このセッションで自分が書いたコードをレビューする場合は、しきい値を 70% 以上に下げてください。今なら修正コストはほぼゼロで、git blame の手順も省略できます（すべて新しいコードです）。ロジックの経路や契約に特に注意してください。新しく書かれたコードでは、バグの多くがそこに潜んでいます。

指摘件数の上限： 報告対象の指摘事項が 8〜10 件を超える場合、何かがおかしいと考えてください。コードに壊滅的な問題がある（その場合は概要で明記してください）か、しきい値が低すぎるかのどちらかです。優先順位を厳しく付けてください。長文のレビューは無視されます。

重要なコード変更ごとに、最も起こりやすい 3 つの障害モードは何かを考えてください。この問いは、行ごとのレビューでは見落としがちなアーキテクチャレベルのバグを見つけるのに役立ちます。個々の行は問題なさそうに見えても、全体の設計に抜けがある AI 生成コードでは特に有効です。

スコアを付ける前に、上記の AI セルフチェックリストを実行してください。根拠を示したり、問題を引き起こす入力を具体的に作り出したりできない場合は、その指摘事項についてステップ 4 に戻るか、スコアを下げてください。報告してはいけません。

ステップ 6：報告する

指摘事項を深刻度別にまとめ、具体的な修正方法を示します。出力形式は下記を参照してください。

共通パターン（すべての言語）

言語横断のバグカタログ全体については、references/universal-patterns.md を読んでください。

レビューを完了する前に、次の 10 項目を必ず確認してください。

ロジックエラー
null または値が存在しない場合の危険性
エラー処理の不足
競合状態と共有状態の問題
リソースリークとライフサイクルの不整合
境界条件やエッジケースでの破損
API とデータ契約の不整合
実際に性能を低下させる問題
正確性に関わる規約違反
対象の動作を立証できていないテスト

基準はシンプルです。誤った結果を返したり、現実的な経路でクラッシュしたり、時間の経過とともに気付かれないまま劣化したりする可能性があるものは、レビュー対象に含めてください。

大規模なコードベースでの優先順位付け

100 ファイルを超えるリポジトリ全体をレビューする場合、すべてを読むことはできません。優先順位を付けてください。

最近変更されたファイル（git log --since='2 weeks ago' --name-only）—新しいコードほどバグが多く含まれます
重要な処理経路 — 認証、決済、データの変更、API ハンドラー、ミドルウェア
エントリーポイント — メインファイル、ルート定義、CLI コマンド、イベントハンドラー
テストのないファイル — git ls-files '*.ts' | while read f; do test -f "${f%.ts}.test.ts" || echo "$f"; done
複雑なファイル — 長い関数、循環的複雑度が高いもの、分岐が多いもの
共有ユーティリティ — ここでのバグはコードベース全体に広がります

対象外：ベンダー提供のコード、生成されたファイル、テスト用フィクスチャやスナップショット、ドキュメント、静的アセット。

対象を絞ったレビュー（差分や特定のファイル）の場合は、変更された公開インターフェース、共有ユーティリティ、マイグレーション、並行処理の境界から確認し、その後、変更対象のファイル全体と直接の呼び出し元・呼び出し先を読みます。コンテキストが重要です。単独では問題なさそうな関数でも、誤った方法で呼び出されている場合があります。リポジトリ全体を順番に読むのではなく、テストと静的解析を使って、疑わしい問題を検証してください。

言語：TypeScript / JavaScript

TS/JS のバグパターンの全カタログについては、references/typescript.md をお読みください。主なポイントは次のとおりです。

Promise の落とし穴：await の不足、未処理の拒否、Promise.all の部分的な失敗、async void
型の絞り込みの不備：型アサーション（as）による実行時チェックの回避、判別可能なユニオン型の網羅性
クロージャーの落とし穴：ループやエフェクト内の古いクロージャー、非同期コールバックでキャプチャされた変更可能な変数
React 固有の問題：依存配列の不足、レンダリング中の状態更新、エフェクト内のメモリーリーク
Node 固有の問題：未処理のストリームエラー、EventEmitter の error イベントハンドラーの不足

言語：Python

Python のバグパターンの全カタログについては、references/python.md をお読みください。主なポイントは次のとおりです。

変更可能なデフォルト引数：def foo(items=[]) — 呼び出し間でリストが共有されます
例外処理：KeyboardInterrupt／SystemExit を捕捉する裸の except:、例外チェーンでのコンテキストの喪失
イテレーターの枯渇：ジェネレーターが気付かないうちに 2 回消費される、map()／filter() がリストではなくイテレーターを返す
インポート時の副作用：循環インポート、インポート時に実行されるモジュールレベルのコード
非同期処理の落とし穴：同期処理と非同期処理の混在、イベントループのブロック、await の不足
Dataclass／pydantic のバグ：default_factory のない変更可能なデフォルトフィールド、バリデーターの副作用、信頼できない入力に対する model_validate() の型変換
属性名の誤記：通常のクラスでは self.nmae = name によって気付かないうちに新しい属性が作成されます。__slots__ または @dataclass(slots=True) を使用してください

言語：Bash / Shell

Shell のバグパターンの全カタログについては、references/shell.md をお読みください。主なポイントは次のとおりです。

単語分割：引用符で囲まれていない変数が空白で分割される、予期しない場所でのグロブ展開
終了コードのマスキング：パイプによって失敗が隠される（cmd1 | cmd2 では cmd2 のみを確認）、local／export 宣言によって $(...) の失敗がマスキングされる
シグナル処理：クリーンアップ用のトラップの不足、バックグラウンド化されたプロセスがクリーンアップされない
移植性：#!/bin/sh スクリプト内の bash 固有構文、GNU と BSD のツールの違い

言語：Java

Java のバグパターンの全カタログについては、references/java.md をお読みください。主なポイントは次のとおりです。

Quarkus：CDI スコープのスレッドセーフ性（@ApplicationScoped と変更可能な状態の組み合わせ）、リアクティブパイプラインでの @RequestScoped の喪失、サブスクライブされない Uni／Multi、ネイティブイメージでのリフレクション、開発サービスの設定の乖離（本番環境での drop-and-create）
Spring Boot：@Transactional のプロキシに関する落とし穴（自己呼び出し、非 public、final、検査例外）、SecurityFilterChain の順序、WebFlux でのブロッキング呼び出し、Reactor のコンテキスト／MDC の喪失
Java 全般：null 許容値に対する Optional.of()、ストリームの再利用、try-catch の外へ漏れる遅延評価、ConcurrentHashMap の確認と実行の分離、equals/hashCode の契約、ラムダ式内で握りつぶされる検査例外
モダン Java 17 以降：synchronized による仮想スレッドのピン留め、Loom による ThreadLocal のメモリー爆発、sealed class での IncompatibleClassChangeError、StructuredTaskScope のリーク
AI 生成 Java：フレームワークの混同（CDI での @Autowired）、過度に複雑なジェネリクス、並行処理への配慮不足（発生率 2 倍）、セキュリティの近道（発生率 1.5〜2 倍）

言語：Infrastructure as Code

IaC のバグパターンの全カタログについては、references/iac.md をお読みください。主な内容は以下のとおりです。

Terraform：リソースの依存関係の誤りや欠落、create_before_destroy に関するライフサイクルの問題、手動変更によるステートのドリフト、データソースの競合状態
Ansible：ハンドラーが通知されない、変数の優先順位に関する予期しない動作、未定義変数を含む when 条件、冪等性の違反
Helm：デプロイ時まで表面化しないテンプレートのレンダリングエラー、値の型の不一致、必須値の欠落
Kubernetes：正常な Pod を終了させるライブネスプローブ、OOMKill を引き起こすリソース制限、高可用性に必要な PDB の欠落
ArgoCD：本番環境での prune を伴う自動同期、同期ウェーブの順序、ヘルスチェックの設定ミス、app-of-apps のクラスタターゲティング
Docker：ENTRYPOINT のシェル形式と exec 形式、誤ったステージからのマルチステージ COPY、FROM 間での ARG のスコープ、.dockerignore の欠落
Compose：condition: service_healthy のない depends_on（起動順序の競合状態）、ヘルスチェックのない restart: always（クラッシュループが無限に続く）、version フィールドが残っている（Compose v2 以降は非推奨）
Proxmox/LXC：API トークンの権限が広すぎる、keyctl=1 を指定せずに LXC の nesting=1 を指定する（コンテナ内で Docker が失敗する）、Terraform telmate/proxmox プロバイダーのバージョンが固定されていない（互換性を破る変更）、Proxmox とゲスト OS の cloud-init ネットワーク設定の不一致、リンククローンで対応できる場合に full_clone を使用する

CI/CD パイプライン

パイプラインのみで見つかった問題は ci-cd に振り分けてください。このリファレンスは、アプリケーションの変更をデリバリー境界を越えて追跡する際の候補コンテキストであり、2 回目のパイプライン監査ではありません。

CI/CD のバグパターンの全カタログについては、references/cicd-pipelines.md をお読みください。主な内容は以下のとおりです。

GitLab CI/CD：rules: と only:/except: の混在（警告なく拒否される）、条件のない最後のルールによって不要なジョブが作成される、workflow:rules がなくパイプラインが重複する、rules: で dotenv 変数を使用する（その時点ではまだ存在しない）、保護変数が保護されていないブランチでは警告なく空になる
GitHub Actions：ユーザーが制御する入力値を含む ${{ }} による式インジェクション、GITHUB_TOKEN の権限範囲が広すぎる、再利用可能なワークフローの入力型の不一致、誤った実行をキャンセルする concurrency group の不具合
Forgejo Actions：GitHub Actions との互換性の差（機能の欠落、ランナーの動作の違い、シークレットの処理の違い）
ArgoCD の高度なパターン：ApplicationSet ジェネレーターの衝突、複数ソースの Application に関する落とし穴、アノテーションベースの同期オプションによる予期しない動作の変更、プログレッシブデリバリーのロールバック順序
Terraform の高度なパターン：ステートロックの競合状態、ワークスペースの分離の失敗、プロバイダーエイリアスの混同、moved ブロックによるプランの破損、import ブロックの制限

AI 時代のパターン

具体的な動作上の欠陥を見つけるために、このリファレンスを使用してください。命名、スタイル、抽象化の好みは code-simplification に、脆弱性に関する指摘は security-audit に該当します。パターンとの一致や過去の統計は調査のきっかけであり、レビュー対象コードに関する証拠ではありません。

AI 時代のバグパターンの全カタログについては、references/ai-age-patterns.md をお読みください。主な内容は以下のとおりです。

AI 生成コードの不審なパターン：実在しない API や依存関係（サンプルの 5 件に 1 件）、古い学習データに基づく非推奨パターン、過剰に防御的なエラー処理、不要な抽象化、安全でないデフォルト設定
エージェント型 AI のパターン：プロンプトインジェクション（OWASP LLM 2025 の第 1 位）、LLM API 呼び出しに対するレート制限の欠落、コンテキストウィンドウのオーバーフロー、ストリーミングに関するエッジケース、ツール／関数呼び出しの検証不足
LLM SDK のバグ：プロバイダー SDK でのストリーミングとツール呼び出しの相互作用、該当する場合の推論ブロックの保持、構造化出力に関する落とし穴、トークン制限またはデフォルト値の欠落
MCP の脆弱性：コマンドインジェクション（サーバーの 43%）、ツールポイズニング（オープンソースサーバーの 5%）、パストラバーサル、SSRF、テナント間のデータ漏えい

データベース

データベースのバグパターンの全カタログは、references/databases.md を参照してください。主な項目は次のとおりです。

一般的な SQL：トランザクションの誤用（一部だけ書き込まれる、ロールバックがない）、NULL の扱い（NULL を含む NOT IN は 0 行を返す）、マイグレーションのバグ（既存のテーブルに DEFAULT なしで NOT NULL を追加する）
PostgreSQL：timestamp と timestamptz の混同、コネクションプールの枯渇、jsonb 演算子の取り違え（-> と ->>）、トランザクション中のアイドル状態による autovacuum のブロック
MongoDB：updateOne/updateMany にプレーンな置換ドキュメントを渡す（無効な更新ドキュメント）、フィールド名のタイプミスにより何も一致しないままになる、書き込み保証 w:0 によるデータ損失、スキーマレスな型の不整合
MySQL/MariaDB：非 strict モードでのデータのサイレントな切り詰め、utf8 は真の UTF-8 ではない（utf8mb4 を使用する）、GROUP BY が任意の値を返す
MSSQL：@@IDENTITY と SCOPE_IDENTITY() の違い、VARCHAR は Unicode を格納できない（NVARCHAR を使用する）、ORDER BY のない TOP
ORM の落とし穴：N+1 クエリ、古いエンティティキャッシュ、列挙型を序数で保存する（並べ替えるとデータが壊れる）、本番環境での自動 DDL

言語：Go

Go のバグパターンの全カタログは、references/go.md を参照してください。主な項目は次のとおりです。

ゴルーチンリーク：受信側のないチャネルでブロックされるゴルーチン、context／完了シグナルがない、WaitGroup がない
nil インターフェースの落とし穴：型付き nil ポインターを保持するインターフェースは nil ではありません。(*MyError)(nil) として返された error は nil チェックに失敗します
defer の順序：LIFO で実行されること、クロージャによる参照キャプチャ、ループ内の defer によるファイル記述子の枯渇
チャネルのデッドロック：同じゴルーチン内でのバッファーなしチャネルの送受信、二重 close によるパニック、ループ内でのタイマー割り当てとバージョンに依存する保持
エラーのラップ：fmt.Errorf における %s と %w の使い分け、errors.Is() ではなく == を使ったセンチネルエラーの比較、Unwrap() がないカスタムエラー
Context リーク：defer cancel() を使わない context.WithCancel／WithTimeout、リクエストスコープの Context を無視する
データ競合：並行する map への書き込み（致命的なパニック）、共有スライスへの append、同期なしの読み取り・変更・書き込み、CI で -race を実行しない
ループ変数のキャプチャ：Go 1.22 より前のクロージャキャプチャのバグ。最初に go.mod を確認してください。go 1.22 以上なら反復ごとのセマンティクス（安全）、1.22 未満ならループ変数はすべてのゴルーチン／クロージャで共有されます（典型的なキャプチャバグ）。この確認はバージョンに依存するため、指摘する前に go.mod を読んでください。go.mod がない場合は、バージョン条件が未確認であることを明記してください。バージョンに依存するバグを確定事項として報告しないでください。

その他の言語

Rust および専用のリファレンスファイルがないその他の言語では、汎用パターン（セクション 1～10）のみを適用してください。言語固有の確認は汎用パターンに限られていたことをレポートに記載してください。

指摘しない項目

スタイル／品質に関する問題 - これは code-simplification の担当です。
セキュリティの脆弱性 - これは security-audit の担当です。
既存のバグ - 現在の変更で触れていない行の問題（差分をレビューする場合）。
リンター／コンパイラーで検出される問題 - インポート漏れ、型エラー、フォーマットの問題。これらはツールチェーンで処理されます。
意図的なトレードオフ - 「Y のために X を行う」と説明するコードコメントは、意図を示しています。ただし、その意図に反する不具合が確認された場合は指摘してください。
テスト専用コード - テスト用フィクスチャ／ヘルパーでエラー処理を緩和するのは、多くの場合問題ありません。
境界における防御的なコード - 外部データの入力検証は適切であり、バグではありません。
既知のフレームワーク特有の挙動 - 不適切に見えても、そのフレームワークでは慣用的なパターン。
イシューへの参照がある TODO - // TODO(#1234) は、問題を認識していることを示しており、怠慢ではありません。
生成コード／ベンダーコード - ロックファイル、コンパイル済み出力、自動生成された型、ベンダー依存関係、ORM のマイグレーション。
以前にレビューしたコード - セッション中に複数回呼び出された場合は、前回のレビュー以降の変更に焦点を当ててください。
書き換えの要求 - 現在の構造が正確性または保守性を妨げていない限り、書き換えを要求しないでください。
テスト全般の不足 - 特定の動作やリスクをカバーする必要がある場合に限り、テスト不足を指摘してください。

重大度の分類

報告する各指摘（確信度 80 以上）には、共通の重大度基準を使用します。

P0 - 必ず修正：通常の使用でクラッシュ、データ破損、または誤った結果を引き起こします。一般的な経路での null 参照、データ損失、正確性に影響する競合状態、失敗を隠すエラー伝播の破損、ロジックバグによる認証バイパスなど、セキュリティに隣接するロジックエラーが含まれます。
P1 - 修正すべき：現実的な特定の条件下で問題を引き起こす、または時間の経過とともに信頼性を低下させます。エッジケースでのクラッシュ、リソースリーク、いずれ顕在化するパフォーマンス上の罠、外部操作でのエラー処理不足、このコードベースでバグの原因となる規約違反が含まれます。
P2 - できれば修正：優先度の低い正確性リスク、確認済みのバグに対する対象を絞った回帰テストの不足、または将来の障害につながる可能性がある保守性の問題。
P3 - バックログ：実際に存在するものの、緊急性が低く、レビュー対象の変更を妨げるべきではないフォローアップ。
info - 情報：確認済みの所見で、直ちに対応する必要はありません。

目安：これが原因で午前 2 時に誰かを起こすなら P0 です。次のスプリントまで待てるなら P1 です。バックログに入れるべきでも、現実的な障害の可能性があるなら P2／P3 です。

出力形式

references/report-format.md のレポートテンプレートを使用してください。重大度ごとに分類し、修正前／修正後を示す指摘用テンプレートと、確認した項目および実行した、または利用できなかったリンターを記載する、指摘のないレビュー用テンプレートがあります。最終レポートを書く前に読んでください。

参照ファイル

references/universal-patterns.md - 言語を問わないバグパターンと障害モード
references/typescript.md - TypeScript および JavaScript のバグパターン
references/python.md - Python のバグパターン
references/shell.md - シェルのバグパターン
references/java.md - Java のバグパターン
references/go.md - Go のバグパターン
references/iac.md - Infrastructure as Code のバグパターン
references/cicd-pipelines.md - CI/CD パイプラインのバグパターン
references/ai-age-patterns.md - AI 時代における正確性のパターンと、ハルシネーションに起因するバグ
references/databases.md - アプリケーションレベルのデータベースのバグパターン
references/report-format.md - 指摘および指摘のないレビュー用レポートテンプレート（ステップ 6 で読む）

出力契約

完全な契約については、references/output-contract.md を参照してください。

スキル名： CODE-REVIEW
成果物の分類： audits
モード： 常時有効。すべての呼び出しで、references/output-contract.md に記載されているレポートのサイズと証拠に関するルールを適用します。
成果物のパス： docs/local/audits/code-review/<YYYY-MM-DD>-<slug>.md
重大度基準： P0 | P1 | P2 | P3 | info（共通契約を参照）。

ルール

指摘する前に読む。 全文脈を読んでいないコードは、決して指摘しないでください（AI Self-Check を参照）。
バグか、スタイルか？ 指摘内容がバグなのかスタイル上の問題なのか判断に迷ったら、「誤った動作を引き起こすか？」と考えてください。そうでなければ指摘を見送り、スタイルの問題や脆弱性は「指摘しないもの」に従って振り分けます。
発生箇所ごとではなく、バグごとに1件の指摘。 同じパターンが5つのファイルに存在する場合は、影響する箇所を示して1回だけ報告してください。報告を水増ししないでください。
修正方法を示す。 すべての指摘に、問題の説明だけでなく、具体的なコード修正を含めてください。修正方法を示せない場合、その指摘は十分に具体的ではありません。
却下された指摘を繰り返さない。 このセッションでユーザーが指摘を認識した、または却下した場合、以降の呼び出しで再度報告しないでください。ユーザーは一度聞いています。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: テスト・品質
インストール数: 58
GitHub スター: 10

問題を報告