mcpField
C
conventional-commits

conventional-commits

github.com/lelborn開発047 回インストール2 週間前に更新
リポジトリ

conventional-commits について

実際の変更内容に基づいて、機械可読な Conventional Commits を作成するためのスキルです。コミット形式や SemVer への影響、変更履歴の整理方法を扱います。

主な機能

  1. 01差分に基づくコミット種別の選択
  2. 02ヘッダー、スコープ、本文、フッターの形式
  3. 03破壊的変更のマーカー
  4. 04コミットメッセージの形式確認
  5. 05変更履歴の分類ガイド

活用シーン

  1. 01コード変更のコミットメッセージ作成
  2. 02互換性を壊す API 変更の明示
  3. 03コミットメッセージの形式確認

インストール

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

$npx skills add https://github.com/lelborn/skills --skill conventional-commits

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

詳細

Conventional Commits

Conventional Commits v1.0.0 に従い、コミットメッセージに機械で読み取れる意味を持たせます。適切に整えられた履歴があれば、ツールで SemVer のバージョンを更新したり、変更履歴を生成したりでき、読者も差分を開かずに git log を確認できます。ただし、すべてのコミットがこの形式に従っている場合に限ります。依頼されるのを待たず、デフォルトで適用してください。

形式

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

必須なのはヘッダーだけです。docs: fix typo in readme は、それだけで完全かつ有効なコミットです。

Type — 依頼内容ではなく差分から判断する

ユーザーが変更をどう呼んだかではなく、その変更が何をするかに基づいてタイプを選びます。「ログインページの整理」は fix、refactor、style のいずれにもなり得ます。判断する前に git diff --staged を確認してください。

Type用途SemVer
feat新機能MINOR
fixバグ修正PATCH
docsドキュメントのみ—
styleコードの意味を変えない書式変更—
refactorバグ修正でも機能追加でもない変更—
perfパフォーマンスの改善—
testテストの追加または修正—
buildビルドシステム、ツール、依存関係—
ciCI の設定とスクリプト—
choresrc やテストに触れないメンテナンス—
revert以前のコミットを取り消す—

feat／fix はユーザーから見える動作に関するものです。refactor は内部のみの変更です。差分が複数のタイプにまたがる場合は、すべてに無理に1つのタイプを当てはめるのではなく、論理的な変更ごとにコミットを分けるサインです。取り消しの場合は revert を使い、取り消した SHA を示すフッターを付けてください（Refs: 676104e）。

フィールド

  • Scope — 影響を受ける領域を示す任意の名詞で、括弧で囲みます（fix(auth):）。変更が1つのモジュール／コンポーネントに限定される場合に追加し、既存の履歴と一貫したスコープを保ってください。
  • Description — 命令形（「added」／「adds」ではなく「add」）、約72文字以内、小文字、末尾にピリオドなし、具体的な内容にします。fix: bug より fix: handle empty array in parseArgs が適切です。
  • Body — 任意です。Description の後に空行を1行入れます。差分を1行ずつ説明するのではなく、変更の 理由 を説明します。理由が明らかでない場合にのみ含めてください。
  • Footers — 任意です。Body の後に空行を1行入れます。Token: value または Token #123 の形式です。トークン内のスペースは - に置き換えます（Reviewed-by、Co-authored-by）。情報がある場合にのみ追加し、課題番号やレビュアーを捏造しないでください。

破壊的変更

破壊的変更とは、利用者がコードを変更しなければならなくなる変更です。API の削除／名前変更、デフォルト値の変更、レスポンス形式の変更などが該当します。次のいずれか、または両方で明示してください。

  • コロンの前に ! を付ける：feat(api)!: drop support for legacy tokens
  • フッターを付ける：BREAKING CHANGE: <破壊される内容と移行方法>

タイプにかかわらず、SemVer の MAJOR になります（fix! でも破壊的変更です）。移行方法が明らかでない場合は、フッターも含めてください。BREAKING CHANGE（同義語の BREAKING-CHANGE）を除き、すべて大文字と小文字を区別しません。BREAKING CHANGE は大文字でなければなりません。

例

feat(lang): add Polish translation

fix: prevent racing of requests

Introduce a request id and dismiss responses from any but the latest request.

Refs: #123

feat(api)!: send an email when a product ships

BREAKING CHANGE: the shipment webhook no longer includes the deprecated
`email_sent` flag; read shipment state from `status` instead.

メッセージのレビュー

次の点を確認してください。タイプがない、またはタイプの後に : がない。Description が空、またはプレフィックスの直後にない。Body／Footer が空行で区切られていない。フッタートークンにスペースが含まれている（BREAKING CHANGE を除く）。BREAKING CHANGE が大文字でない。破壊的な差分にマーカーがない。タイプが差分に合っていない。

履歴からの CHANGELOG 作成

タイプごとにまとめ（feat → Features、fix → Fixes…）、破壊的変更のマーカーが付いたものはタイプにかかわらず BREAKING CHANGES に記載します。ユーザーが履歴全体を求めていない限り、ユーザー向けの意味がないタイプ（chore、style、ci など）は省略します。関連する keep-a-changelog スキルでは、この内容を詳しく扱います。

コメント

Markdown 対応