jpskill.com
✍️ ライティング コミュニティ

conventional-commits

ユーザーがコミットメッセージの作成を依頼した際に、ステージングされた変更内容に基づいて、高品質なConventional Commits形式のメッセージを生成し、コミット作業を支援するSkill。

📜 元の英語説明(参考)

This skill should be used when the user asks to "create commit", "commit message", "git commit", "generate commit message", "write a commit", "commit local repository changes", or describes changes to be committed. Generates high-quality Conventional Commits formatted messages based on staged changes without executing the commit command.

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

一言でいうと

ユーザーがコミットメッセージの作成を依頼した際に、ステージングされた変更内容に基づいて、高品質なConventional Commits形式のメッセージを生成し、コミット作業を支援するSkill。

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

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

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

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

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

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して conventional-commits.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → conventional-commits フォルダができる
  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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Conventional Commits のガイドライン

ステージングされた変更に基づいて、Conventional Commits の仕様に従って、プロフェッショナルなコミットメッセージを生成します。

メッセージ構成のルール

  1. フォーマットの強制:

    • <type>(<scope>): <subject> のフォーマットを使用してメッセージを構成します。
    • 空白行と詳細な <body> を含めます。body が技術的な変更を反映していることを確認してください。
    • 最終的な出力をMarkdown コードブロックで囲みます。

  2. 適切なタイプの選択:

    • 標準タイプである feat, fix, docs, style, refactor, perf, test, chore に従ってください。
    • 詳細な選択基準については、references/type-definitions.md を参照してください。

  3. スコープの抽出 (パスベースのみ):

    • スコープは、ステージングされた変更のファイルパスから厳密に導出します。
    • 優先度 1 (モジュール): すべての変更がその中に含まれる場合、トップレベルまたはセカンドレベルのディレクトリ名（例：src/components/、api/）を使用します。
    • 優先度 2 (プラットフォーム): 変更が特にそれらのフォルダ内にある場合は、ios または android を使用します。
    • 優先度 3 (グローバル): 変更が 3 つ以上のトップレベルモジュールに影響を与える場合、またはルートレベルの構成を含む場合にのみ、* を使用します。
    • 詳細な抽出ルールについては、references/scope-guidelines.md を参照してください。

  4. サブジェクト行の作成:

    • ユーザー入力の統合: 引用符で囲まれたテキストを <subject> としてそのまま使用します。プロンプト内の他の指示語は無視します。
    • 簡潔な生成: テキストが提供されていない場合は、ステージングされた diff に基づいて、繁体字中国語 (台湾) で簡潔なサブジェクトを生成します。
    • 長さの制限: サブジェクト行を 50 文字未満に保ちます。

  5. 本文コンテンツの作成:

    • Diff の分析: <body> は、git diff --cached の分析からのみ生成します。
    • ハルシネーションの禁止: ユーザーの指示、ツールのメタデータ、または会話のコンテキストを除外します。
    • 言語ポリシー: 説明には繁体字中国語 (台湾) を使用し、技術用語は英語のままにします。
    • 要件: すべてのコミットに <body> を含めます。小さな変更であっても、git diff から少なくとも 1 つの技術的な箇条書きを抽出します。
    • 焦点: コードで「何が」変更されたかを説明します（例：関数を変更した、スタイルプロパティを変更した）。

  6. 言語制約の適用:

    • type: 英語。
    • scope: 英語。
    • subject: そのまま (提供されている場合) または繁体字中国語 (台湾)。
    • body: 繁体字中国語 (台湾) と英語の技術用語。

  7. ステージングされた変更の処理:

    • ステージングされた変更のみを分析します。
    • 変更がステージングされていない場合は停止し、ユーザーに通知します: "目前沒有已暫存（staged）的變更，請先執行 git add。"

  8. 出力動作の制御:

    • git コミットを実行するためにツールや関数を呼び出すことを厳格に禁止します。生成されたテキストのみを出力します。
    • ツールの使用を git diff --cached と git ls-files に制限します。

  9. インタラクティブな改善の実装:

    • 改善プロンプトの追加: 最初の生成 (フェーズ 1) 中にのみ、改善プロンプトを追加します。

      「💡 提示：若本次改動較複雜，建議提供以下資訊，我將為你潤飾更專業的描述： 背景/動機：(說明為什麼改) 關鍵改動：(說明做了什麼) 預期影響：(說明改完後的好處)」

    • コンテキストによる再生成: ユーザーが追加のコンテキストを提供した場合、自動的に生成された body を洗練されたバージョンに置き換えます。
    • 沈黙の維持: フェーズ 2 (コンテキストが提供された後) で改善プロンプトを繰り返すことは避けてください。

運用ワークフロー

フェーズ 1: 初期生成

  1. git diff --cached を実行してコンテキストを収集します。
  2. 変更がステージングされていない場合は停止します。
  3. diff を分析して、論理的な type を特定します。
  4. 代表的なディレクトリ名に基づいて scope を決定します。
  5. 優先順位ルールに従ってサブジェクト行を作成します。
  6. メッセージテキスト (サブジェクト + 必須の本文) を作成します。
  7. テキストを Markdown コードブロックで出力します。
  8. 出力後、すべてのアクションを停止します。それ以上のツールを呼び出すことは避けてください。
  9. 改善プロンプトを追加します。

フェーズ 2: コンテキストによる改善

  1. ユーザーが "背景/動機"、"關鍵改動"、または "預期影響" を提供した場合、古い body を破棄します。
  2. ユーザーが提供したコンテキストを主要なソースとして使用し、diff からの技術的な事実で補完します。
  3. 洗練されたコミットメッセージを新しいコードブロックで出力します。
  4. 停止し、改善プロンプトを再度提供しないでください。

追加リソース

参照ファイル

  • references/type-definitions.md - コミットタイプの詳細な定義。
  • references/scope-guidelines.md - 包括的なスコープ抽出ルール。

サンプルファイル

  • examples/feature-example.md - 新機能コミットの例。
  • examples/fix-example.md - バグ修正コミットの例。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Conventional Commits Guidelines

Follow the Conventional Commits specification to generate professional commit messages based on staged changes.

Message Composition Rules

  1. Enforce Format:

    • Construct the message using the format: <type>(<scope>): <subject>
    • Include a blank line followed by a detailed <body>. Ensure the body reflects technical changes.
    • Wrap the final output in a Markdown code block.

  2. Select Appropriate Type:

    • Follow the standard types: feat, fix, docs, style, refactor, perf, test, chore.
    • Refer to references/type-definitions.md for detailed selection criteria.

  3. Extract Scope (Path-Based Only):

    • Derive the scope strictly from the file path of the staged changes.
    • Priority 1 (Module): Use the top-level or second-level directory name (e.g., src/components/, api/) if all changes fall within it.
    • Priority 2 (Platform): Use ios or android if changes are specifically inside those folders.
    • Priority 3 (Global): Use * only if changes affect more than three top-level modules or involve root-level configuration.
    • Refer to references/scope-guidelines.md for detailed extraction rules.

  4. Compose Subject Line:

    • Integrate User Input: Use text provided in quotes verbatim as the <subject>. Ignore other instructional words in the prompt.
    • Generate Concisely: Generate a concise subject in Traditional Chinese (Taiwan) based on the staged diff if no text is provided.
    • Limit Length: Keep the subject line under 50 characters.

  5. Draft Body Content:

    • Analyze Diff: Generate the <body> exclusively from git diff --cached analysis.
    • Prohibit Hallucination: Exclude user instructions, tool metadata, or conversation context.
    • Language Policy: Use Traditional Chinese (Taiwan) for descriptions, keeping technical terms in English.
    • Requirement: Include a <body> for every commit. Extract at least one technical bullet point from the git diff even for small changes.
    • Focus: Describe "what" changed in the code (e.g., modified a function, changed a style property).

  6. Apply Language Constraints:

    • type: English.
    • scope: English.
    • subject: Verbatim (if provided) or Traditional Chinese (Taiwan).
    • body: Traditional Chinese (Taiwan) with English technical terms.

  7. Handle Staged Changes:

    • Analyze ONLY staged changes.
    • Stop and inform the user if no changes are staged: "目前沒有已暫存（staged）的變更，請先執行 git add。"

  8. Control Output Behavior:

    • Follow the strict prohibition on calling tools or functions to execute git commits. Output the generated text only.
    • Limit tool usage to git diff --cached and git ls-files.

  9. Implement Interactive Refinement:

    • Append Refinement Prompt: Append the refinement prompt ONLY during the initial generation (Phase 1):

      「💡 提示：若本次改動較複雜，建議提供以下資訊，我將為你潤飾更專業的描述： 背景/動機：(說明為什麼改) 關鍵改動：(說明做了什麼) 預期影響：(說明改完後的好處)」

    • Regenerate with Context: Replace the automatically generated body with a polished version if the user provides additional context.
    • Maintain Silence: Avoid repeating the refinement prompt in phase 2 (after context is provided).

Operational Workflow

Phase 1: Initial Generation

  1. Execute git diff --cached to gather context.
  2. Stop if no changes are staged.
  3. Analyze the diff to identify the logical type.
  4. Determine the scope based on the representative directory name.
  5. Compose the subject line following priority rules.
  6. Draft the message text (Subject + Mandatory Body).
  7. Output the text in a Markdown code block.
  8. Stop all actions after output. Avoid calling further tools.
  9. Append the Refinement Prompt.

Phase 2: Contextual Refinement

  1. Discard the old body if user provides "背景/動機", "關鍵改動", or "預期影響".
  2. Use the user-provided context as the primary source, supplemented by technical facts from the diff.
  3. Output the polished commit message in a new code block.
  4. Stop and do not provide the refinement prompt again.

Additional Resources

Reference Files

  • references/type-definitions.md - Detailed commit type definitions.
  • references/scope-guidelines.md - Comprehensive scope extraction rules.

Example Files

  • examples/feature-example.md - Example of a new feature commit.
  • examples/fix-example.md - Example of a bug fix commit.