jpskill.com
🛠️ 開発・MCP コミュニティ

code-review-expert

現在のGitの変更内容を、経験豊富なエンジニアの視点から専門的にコードレビューし、SOLID原則違反やセキュリティリスクを検出し、実行可能な改善策を提案するSkill。

📜 元の英語説明(参考)

Expert code review of current git changes with a senior engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements.

🇯🇵 日本人クリエイター向け解説

一言でいうと

現在のGitの変更内容を、経験豊富なエンジニアの視点から専門的にコードレビューし、SOLID原則違反やセキュリティリスクを検出し、実行可能な改善策を提案するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o code-review-expert.zip https://jpskill.com/download/9083.zip && unzip -o code-review-expert.zip && rm code-review-expert.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9083.zip -OutFile "$d\code-review-expert.zip"; Expand-Archive "$d\code-review-expert.zip" -DestinationPath $d -Force; ri "$d\code-review-expert.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して code-review-expert.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → code-review-expert フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

コードレビューのエキスパート

概要

SOLID原則、アーキテクチャ、削除候補、およびセキュリティリスクに焦点を当てて、現在の git の変更を構造的にレビューします。ユーザーが変更の実装を要求しない限り、デフォルトではレビューのみの出力とします。

重要度レベル

レベル 名前 説明 アクション
P0 クリティカル セキュリティ脆弱性、データ損失リスク、正確性のバグ マージをブロックする必要あり
P1 ロジックエラー、重大な SOLID 原則違反、パフォーマンスの低下 マージ前に修正すべき
P2 コードの臭い、保守性の懸念、軽微な SOLID 原則違反 この PR で修正するか、フォローアップを作成
P3 スタイル、命名、軽微な提案 オプションの改善

ワークフロー

1) 事前コンテキスト

  • git status -sbgit diff --stat、および git diff を使用して、変更の範囲を特定します。
  • 必要に応じて、rg または grep を使用して、関連するモジュール、使用箇所、およびコントラクトを見つけます。
  • エントリーポイント、所有権の境界、およびクリティカルパス(認証、支払い、データ書き込み、ネットワーク)を特定します。

エッジケース:

  • 変更なし: git diff が空の場合、ユーザーに通知し、ステージングされた変更または特定のコミット範囲をレビューするかどうかを尋ねます。
  • 大きな差分(>500 行): まずファイルごとに要約し、次にモジュール/機能領域ごとにまとめてレビューします。
  • 混在した懸念事項: ファイルの順序だけでなく、論理的な機能ごとに調査結果をグループ化します。

2) SOLID + アーキテクチャの臭い

  • references/solid-checklist.md をロードして、具体的なプロンプトを取得します。
  • 以下を探します。
    • SRP: 無関係な責任を持つ過負荷のモジュール。
    • OCP: 拡張ポイントの代わりに動作を追加するための頻繁な編集。
    • LSP: 期待を破るか、型チェックを必要とするサブクラス。
    • ISP: 未使用のメソッドを持つ幅広いインターフェース。
    • DIP: 低レベルの実装に結び付けられた高レベルのロジック。
  • リファクタリングを提案するときは、それがなぜ凝集度/結合度を改善するのかを説明し、最小限で安全な分割の概要を示します。
  • リファクタリングが自明でない場合は、大規模な書き換えではなく、段階的な計画を提案します。

3) 削除候補 + イテレーション計画

  • テンプレートとして references/removal-plan.md をロードします。
  • 未使用、冗長、または機能フラグがオフになっているコードを特定します。
  • 今すぐ安全に削除計画を立てて延期 を区別します。
  • 具体的なステップとチェックポイント(テスト/メトリクス)を含むフォローアップ計画を提供します。

4) セキュリティと信頼性のスキャン

  • カバレッジのために references/security-checklist.md をロードします。
  • 以下を確認します。
    • XSS、インジェクション(SQL/NoSQL/コマンド)、SSRF、パス・トラバーサル
    • AuthZ/AuthN のギャップ、テナンシーチェックの欠落
    • ログ/env/ファイル内のシークレットリークまたは API キー
    • レート制限、無制限ループ、CPU/メモリのホットスポット
    • 安全でないデシリアライゼーション、脆弱な暗号化、安全でないデフォルト
    • 競合状態: 同時アクセス、チェックしてから実行、TOCTOU、ロックの欠落
  • 悪用可能性影響 の両方を指摘します。

5) コード品質のスキャン

  • カバレッジのために references/code-quality-checklist.md をロードします。
  • 以下を確認します。
    • エラー処理: 飲み込まれた例外、過度に広範な catch、エラー処理の欠落、非同期エラー
    • パフォーマンス: N+1 クエリ、ホットパスでの CPU 負荷の高い操作、キャッシュの欠落、無制限のメモリ
    • 境界条件: null/undefined の処理、空のコレクション、数値境界、オフバイワン
  • サイレント障害または本番環境でのインシデントを引き起こす可能性のある問題をフラグ付けします。

6) 出力形式

レビューを次のように構成します。

## コードレビューの概要

**レビューしたファイル**: X ファイル、Y 行の変更
**全体的な評価**: [APPROVE / REQUEST_CHANGES / COMMENT]

---

## 調査結果

### P0 - クリティカル
(なし、またはリスト)

### P1 - 高
1. **[file:line]** 簡単なタイトル
  - 問題の説明
  - 推奨される修正

### P2 - 中
2. (セクション全体で番号を継続)
  - ...

### P3 - 低
...

---

## 削除/イテレーション計画
(該当する場合)

## 追加の提案
(オプションの改善、ブロックしない)

インラインコメント: ファイル固有の調査結果には、次の形式を使用します。

::code-comment{file="path/to/file.ts" line="42" severity="P1"}
問題の説明と推奨される修正。
::

クリーンなレビュー: 問題が見つからない場合は、以下を明示的に記述します。

  • 何をチェックしたか
  • カバーされていない領域(例:「データベースの移行は検証していません」)
  • 残存リスクまたは推奨されるフォローアップテスト

7) 次のステップの確認

調査結果を提示した後、ユーザーにどのように進めるかを尋ねます。

---

## 次のステップ

X 個の問題が見つかりました (P0: _, P1: _, P2: _, P3: _)。

**どのように進めますか?**

1. **すべて修正** - 提案されたすべての修正を実装します
2. **P0/P1 のみ修正** - クリティカルおよび高優先度の問題に対処します
3. **特定の項目を修正** - 修正する問題を教えてください
4. **変更なし** - レビュー完了、実装は不要

オプションを選択するか、具体的な指示を提供してください。

重要: ユーザーが明示的に確認するまで、変更を実装しないでください。これはレビューファーストのワークフローです。

リソース

references/

ファイル 目的
solid-checklist.md SOLID の臭いのプロンプトとリファクタリングのヒューリスティクス
security-checklist.md Web/アプリのセキュリティとランタイムリスクのチェックリスト
code-quality-checklist.md エラー処理、パフォーマンス、境界条件
removal-plan.md 削除候補とフォローアップ計画のテンプレート
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Code Review Expert

Overview

Perform a structured review of the current git changes with focus on SOLID, architecture, removal candidates, and security risks. Default to review-only output unless the user asks to implement changes.

Severity Levels

Level Name Description Action
P0 Critical Security vulnerability, data loss risk, correctness bug Must block merge
P1 High Logic error, significant SOLID violation, performance regression Should fix before merge
P2 Medium Code smell, maintainability concern, minor SOLID violation Fix in this PR or create follow-up
P3 Low Style, naming, minor suggestion Optional improvement

Workflow

1) Preflight context

  • Use git status -sb, git diff --stat, and git diff to scope changes.
  • If needed, use rg or grep to find related modules, usages, and contracts.
  • Identify entry points, ownership boundaries, and critical paths (auth, payments, data writes, network).

Edge cases:

  • No changes: If git diff is empty, inform user and ask if they want to review staged changes or a specific commit range.
  • Large diff (>500 lines): Summarize by file first, then review in batches by module/feature area.
  • Mixed concerns: Group findings by logical feature, not just file order.

2) SOLID + architecture smells

  • Load references/solid-checklist.md for specific prompts.
  • Look for:
    • SRP: Overloaded modules with unrelated responsibilities.
    • OCP: Frequent edits to add behavior instead of extension points.
    • LSP: Subclasses that break expectations or require type checks.
    • ISP: Wide interfaces with unused methods.
    • DIP: High-level logic tied to low-level implementations.
  • When you propose a refactor, explain why it improves cohesion/coupling and outline a minimal, safe split.
  • If refactor is non-trivial, propose an incremental plan instead of a large rewrite.

3) Removal candidates + iteration plan

  • Load references/removal-plan.md for template.
  • Identify code that is unused, redundant, or feature-flagged off.
  • Distinguish safe delete now vs defer with plan.
  • Provide a follow-up plan with concrete steps and checkpoints (tests/metrics).

4) Security and reliability scan

  • Load references/security-checklist.md for coverage.
  • Check for:
    • XSS, injection (SQL/NoSQL/command), SSRF, path traversal
    • AuthZ/AuthN gaps, missing tenancy checks
    • Secret leakage or API keys in logs/env/files
    • Rate limits, unbounded loops, CPU/memory hotspots
    • Unsafe deserialization, weak crypto, insecure defaults
    • Race conditions: concurrent access, check-then-act, TOCTOU, missing locks
  • Call out both exploitability and impact.

5) Code quality scan

  • Load references/code-quality-checklist.md for coverage.
  • Check for:
    • Error handling: swallowed exceptions, overly broad catch, missing error handling, async errors
    • Performance: N+1 queries, CPU-intensive ops in hot paths, missing cache, unbounded memory
    • Boundary conditions: null/undefined handling, empty collections, numeric boundaries, off-by-one
  • Flag issues that may cause silent failures or production incidents.

6) Output format

Structure your review as follows:

## Code Review Summary

**Files reviewed**: X files, Y lines changed
**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]

---

## Findings

### P0 - Critical
(none or list)

### P1 - High
1. **[file:line]** Brief title
  - Description of issue
  - Suggested fix

### P2 - Medium
2. (continue numbering across sections)
  - ...

### P3 - Low
...

---

## Removal/Iteration Plan
(if applicable)

## Additional Suggestions
(optional improvements, not blocking)

Inline comments: Use this format for file-specific findings:

::code-comment{file="path/to/file.ts" line="42" severity="P1"}
Description of the issue and suggested fix.
::

Clean review: If no issues found, explicitly state:

  • What was checked
  • Any areas not covered (e.g., "Did not verify database migrations")
  • Residual risks or recommended follow-up tests

7) Next steps confirmation

After presenting findings, ask user how to proceed:

---

## Next Steps

I found X issues (P0: _, P1: _, P2: _, P3: _).

**How would you like to proceed?**

1. **Fix all** - I'll implement all suggested fixes
2. **Fix P0/P1 only** - Address critical and high priority issues
3. **Fix specific items** - Tell me which issues to fix
4. **No changes** - Review complete, no implementation needed

Please choose an option or provide specific instructions.

Important: Do NOT implement any changes until user explicitly confirms. This is a review-first workflow.

Resources

references/

File Purpose
solid-checklist.md SOLID smell prompts and refactor heuristics
security-checklist.md Web/app security and runtime risk checklist
code-quality-checklist.md Error handling, performance, boundary conditions
removal-plan.md Template for deletion candidates and follow-up plan