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

code-review-and-commit

まだコミットされていないGitの変更内容を、正確さや品質、プロジェクトのルールに沿っているか確認し、修正を加えて安全かつ最小単位でコミットできる計画を立て、変更を反映させる作業を支援するSkill。

📜 元の英語説明(参考)

Review uncommitted Git changes for correctness, quality, and project convention alignment, then apply fixes and prepare a safe, atomic commit plan. Use when users ask to review code before committing, improve local changes, split work into logical conventional commits, or execute `git add`/`git commit` with clear staging boundaries.

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

一言でいうと

まだコミットされていないGitの変更内容を、正確さや品質、プロジェクトのルールに沿っているか確認し、修正を加えて安全かつ最小単位でコミットできる計画を立て、変更を反映させる作業を支援するSkill。

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

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

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

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

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

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

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

🎯 この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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

コードレビューとコミット

ワーキングツリーの変更に対して、質の高いレビューを実施し、意味のある問題を修正し、理解しやすいコミット履歴を作成します。

ソースの基礎: ローカルの Claude Code エージェントのプロンプト (code-review-and-commit.md) からの改作。

ワークフロー

  1. 現在の変更範囲を検査します。
  2. 正確性と保守性の問題をレビューします。
  3. 必要な修正を適用します。
  4. 更新された変更を検証します。
  5. コミット計画を立てます。
  6. コミットを作成する前に承認を求めます。
  7. コミットを順番に実行し、結果を報告します。

1) 現在の変更範囲を検査する

以下を実行します。

  • git status --short
  • git diff (ステージされていない)
  • git diff --staged (関連する場合)

コミットの境界を提案する前に、変更を関心事 (機能、修正、リファクタリング、テスト、ドキュメント) ごとにマッピングします。

2) レビューの優先順位

次の順序で優先順位を付けます。

  1. 正確性とリグレッション。
  2. セキュリティと秘密情報の漏洩リスク。
  3. 壊れたアーキテクチャまたはプロジェクトパターンの違反。
  4. 動作変更に対するテストの欠落。
  5. 可読性と保守性の向上。

以下についてレビューします。

  • ロジックのバグと未処理のエッジケース。
  • エラー処理または検証の欠落。
  • 変更されたコードパスにおけるパフォーマンスの落とし穴。
  • 型の正確さとドキュメンテーションの品質。簡潔で役立つドキュメントを優先します。
  • 明らかなコードの動作を繰り返す、価値の低いコメント。
  • リソースのライフサイクルの問題 (クリーンアップ、コンテキスト管理)。
  • プロジェクトドキュメントからのリポジトリ規約の違反。

3) 修正を適用する

発見された内容が実行可能で安全な場合は、修正を直接実装します。

  • 要求された作業に対して範囲を狭く保ちます。
  • 正確性のために必要な場合を除き、無関係なリファクタリングは避けてください。
  • 意味のある修正を行うたびに、差分を再確認します。

4) 検証

利用可能な場合は、関連する品質チェック (たとえば、lint、テスト、型チェック) を実行します。

チェックを実行できない場合は、スキップされた内容とその理由を明示的に記述します。

5) コミット計画を立てる

変更を、個別に元に戻すことができるアトミックなコミットにグループ化します。

提案された各コミットには、以下を含めます。

  • コミットの種類と概要 (feat、fix、refactor、test、docs、chore)。
  • ステージングする正確なファイル。
  • このグループ化が首尾一貫している理由。
  • 最終的なコミットメッセージの草案。

コミットメッセージのルール:

  • 命令形を使用します。
  • 件名を簡潔に保ちます (目標 <= 50 文字)。
  • 本文は必要な場合にのみ追加し、理由を説明します。
  • 本文の行は 72 文字付近で折り返します。

6) 承認ゲート

git add または git commit を実行する前に、完全なコミット計画を提示し、承認を要求します。

ユーザーが変更を要求した場合は、計画を修正し、実行する前に再度提示します。

7) 実行と報告

承認後:

  1. 現在のコミットに対して計画されたファイルのみをステージングします。
  2. コミットを作成します。
  3. コミットハッシュと概要で成功を確認します。
  4. 残りのコミットに対して繰り返します。

簡潔な要約で終わります。

  • 作成されたコミット (ハッシュ + 件名)。
  • コミットごとに含まれるファイル。
  • 残りのステージされていない/コミットされていない変更。

出力形式

次の構造を使用します。

  1. 重大度別にグループ化された Review Findings (Critical、Important、Suggestion)。
  2. ファイルレベルの概要を含む Applied Fixes。
  3. Validation Results (実行されたコマンドと結果)。
  4. Proposed Commit Plan (ファイルリスト + メッセージを含む番号付きコミット)。
  5. 承認後の Execution Results。

決定ルール

  • スタイルよりも正確性を優先します。
  • 個人的な好みよりもプロジェクトの規約を優先します。
  • 複数の有効なアプローチが存在する場合は、トレードオフを表面化します。
  • 変更が危険またはアーキテクチャに影響を与える場合は、明示的にエスカレートします。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Code Review and Commit

Perform a high-signal review of working-tree changes, fix meaningful issues, and produce an understandable commit history.

Source basis: adapted from a local Claude Code agent prompt (code-review-and-commit.md).

Workflow

  1. Inspect current change scope.
  2. Review for correctness and maintainability issues.
  3. Apply necessary fixes.
  4. Validate updated changes.
  5. Build a commit plan.
  6. Ask for approval before creating commits.
  7. Execute commits in order and report results.

1) Inspect Current Change Scope

Run:

  • git status --short
  • git diff (unstaged)
  • git diff --staged (if relevant)

Map changes by concern (feature, fix, refactor, tests, docs) before suggesting commit boundaries.

2) Review Priorities

Prioritize in this order:

  1. Correctness and regressions.
  2. Security and secret leakage risks.
  3. Broken architecture or project-pattern violations.
  4. Missing tests for behavior changes.
  5. Readability and maintainability improvements.

Review for:

  • Logic bugs and unhandled edge cases.
  • Missing error handling or validation.
  • Performance pitfalls in changed code paths.
  • Type accuracy and docstring quality; favor concise, useful docs.
  • Low-value comments that restate obvious code behavior.
  • Resource-lifecycle problems (cleanup, context management).
  • Violations of repository conventions from project docs.

3) Apply Fixes

When findings are actionable and safe, implement fixes directly.

  • Keep scope tight to the requested work.
  • Avoid unrelated refactors unless necessary for correctness.
  • Re-check diffs after each meaningful fix.

4) Validate

Run relevant quality checks when available (for example lint, tests, type checks).

If checks cannot run, explicitly state what was skipped and why.

5) Build Commit Plan

Group changes into atomic commits that can be reverted independently.

For each proposed commit include:

  • Commit type and summary (feat, fix, refactor, test, docs, chore).
  • Exact files to stage.
  • Why this grouping is coherent.
  • Final commit message draft.

Commit message rules:

  • Use imperative mood.
  • Keep subject concise (target <= 50 chars).
  • Add body only when needed, explaining why.
  • Wrap body lines near 72 chars.

6) Approval Gate

Before running git add or git commit, present the full commit plan and request approval.

If the user asks for changes, revise the plan and re-present before executing.

7) Execute and Report

After approval:

  1. Stage only planned files for the current commit.
  2. Create the commit.
  3. Confirm success with commit hash and summary.
  4. Repeat for remaining commits.

End with a concise recap:

  • Commits created (hash + subject).
  • Files included per commit.
  • Any remaining unstaged/uncommitted changes.

Output Format

Use this structure:

  1. Review Findings grouped by severity (Critical, Important, Suggestion).
  2. Applied Fixes with file-level summary.
  3. Validation Results (commands run and outcomes).
  4. Proposed Commit Plan (numbered commits with file list + message).
  5. Execution Results after approval.

Decision Rules

  • Prefer correctness over style.
  • Favor project conventions over personal preference.
  • Surface trade-offs when multiple valid approaches exist.
  • Escalate explicitly when changes are risky or architecture-affecting.