mcpField
C
conventional-commits

conventional-commits

github.com/bastos開発757 回インストール13 週間前に更新
リポジトリ

conventional-commits について

開発者やエージェント向けに、Conventional Commits に沿ったコミットメッセージを定めるスキルです。タイプ、スコープ、破壊的変更の表記、説明文の指針を扱います。

主な機能

  1. 01Conventional Commitsのメッセージ構造
  2. 02コミットタイプと任意のスコープ
  3. 03破壊的変更の表記
  4. 04命令形による簡潔な説明
  5. 05セマンティックバージョニングとの関連

活用シーン

  1. 01一貫したGitコミットメッセージの作成
  2. 02マージコミットメッセージの準備
  3. 03変更履歴に使えるコミットの生成

インストール

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

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

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

詳細

Conventional Commits

すべてのコミットメッセージをConventional Commits仕様に従って記述してください。これにより、変更履歴の自動生成、セマンティックバージョニング、より分かりやすいコミット履歴を実現できます。

フォーマットの構造

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

コミットの種類

SemVer に対応するコアタイプ

変更内容に合致する場合はこれらのタイプを使用してください。仕様上、暗黙的な SemVer の意味を持つのはこれらのタイプのみです。

  • feat: - 新機能（セマンティックバージョニングの MINOR に対応）
  • fix: - バグ修正（セマンティックバージョニングの PATCH に対応）
よく使われる追加タイプ
  • docs: - ドキュメントのみの変更
  • style: - コードスタイルの変更（フォーマット、セミコロンの不足など）
  • refactor: - バグ修正や新機能の追加を伴わないコードのリファクタリング
  • perf: - パフォーマンスの改善
  • test: - テストの追加や更新
  • build: - ビルドシステムや外部依存関係の変更
  • ci: - CI/CD 設定の変更
  • chore: - src ファイルや test ファイルを変更しないその他の変更
  • revert: - 以前のコミットの取り消し

スコープ

任意のスコープを指定すると、コードベース内の該当箇所について追加の情報を示せます。

feat(parser): add ability to parse arrays
fix(auth): resolve token expiration issue
docs(readme): update installation instructions

説明

  • タイプ／スコープの後に、コロンとスペースを挟んですぐに記述します

スタイルに関する推奨事項：

  • 命令形を使います（「added feature」や「adds feature」ではなく「add feature」）
  • 先頭の文字を大文字にしません
  • 末尾にピリオドを付けません
  • 72 文字以内（タイプとスコープを含む）を推奨します
  • 読みやすさを高めるため、50 文字以内を推奨します

本文

  • 追加の情報を示す、任意の長めの説明です
  • 説明の後に空行を 1 行入れてから記述します
  • 複数の段落で構成できます
  • 変更の「方法」ではなく「内容」と「理由」を説明します

破壊的変更

破壊的変更は、次の 2 つの方法で示せます。

1. タイプ／スコープに ! を使用する
feat!: send an email to the customer when a product is shipped
feat(api)!: send an email to the customer when a product is shipped
2. BREAKING CHANGE フッターを使用する
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

仕様では BREAKING-CHANGE: も同義のフッタートークンとして扱われますが、プロジェクトの慣習で別途定められていない限り、BREAKING CHANGE: を使用してください。

3. 両方の方法を使用する
chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

例

シンプルな機能追加
feat: add user authentication
スコープ付きの機能追加
feat(auth): add OAuth2 support
本文付きのバグ修正
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
破壊的変更
feat!: migrate to new API client

BREAKING CHANGE: The API client interface has changed. All methods now
return Promises instead of using callbacks.
ドキュメントの更新
docs: correct spelling of CHANGELOG
フッター付きの複数段落の本文
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

ガイドライン

  1. 必ずタイプを使用する - すべてのコミットは、タイプ、コロン、スペースの順で始めます
  2. 命令形を使用する - 「このコミットを適用すると、〜する」という文を完成させるように記述します
  3. 具体的に記述する - 説明から変更内容が明確に伝わるようにします
  4. 対象を絞る - 1 つのコミットにつき、論理的にまとまった変更を 1 つにします
  5. 必要に応じてスコープを使用する - スコープを使うと、コードベース内の変更を分類しやすくなります
  6. 破壊的変更を記録する - 破壊的変更は必ず明確に示します

セマンティックバージョニングとの対応

  • fix: → PATCH バージョンを上げます（1.0.0 → 1.0.1）
  • feat: → MINOR バージョンを上げます（1.0.0 → 1.1.0）
  • BREAKING CHANGE → MAJOR バージョンを上げます（1.0.0 → 2.0.0）

使用する場面

次の場面でこの形式を使用してください：

  • すべての git コミット
  • コミットメッセージの生成
  • プルリクエストのマージコミット
  • ユーザーからコミットメッセージや git コミットについて質問された場合

避けるべきよくある間違い

❌ Added new feature（過去形、大文字始まり） ✅ feat: add new feature（命令形、小文字始まり）

❌ fix: bug（曖昧すぎる） ✅ fix: resolve null pointer exception in user service

❌ feat: add feature（冗長） ✅ feat: add user profile page

❌ feat: Added OAuth support.（過去形、末尾にピリオド） ✅ feat: add OAuth support

コメント

Markdown 対応