mcpField
G
gitmoji-conventional

gitmoji-conventional

github.com/morzecrew開発165 回インストール11 週間前に更新
リポジトリ

gitmoji-conventional について

Gitmoji + Conventional Commits のコミットメッセージを作成・検査するスキルです。タイプの選択や本文、形式を案内し、スクリプトでメッセージを検査します。PR タイトルは検査対象外です。

主な機能

  1. 01主要な変更に基づくコミットタイプの選択
  2. 02Gitmoji と Conventional Commit 形式の適用
  3. 03簡潔で有用なコミット本文の作成
  4. 04メッセージ・ファイル・コミット範囲の検査
  5. 05破壊的変更とリバートの規約への対応

活用シーン

  1. 01コード変更のコミットメッセージを作成
  2. 02ブランチ内のコミットメッセージを監査
  3. 03文書化された規則に沿って PR タイトルを作成

インストール

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

$npx skills add https://github.com/morzecrew/agent-skills --skill gitmoji-conventional

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
commit-format.md
gitmoji-mapping.md
scripts/
check_commit_msg.py

詳細

Gitmoji + Conventional Commits

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

✨ feat(api): add OAuth login support
🐛 fix(auth): handle expired refresh tokens
♻️ refactor(cache): extract eviction policy

形式、破壊的変更のシグナル、revert の形式、フッター、SemVer との対応、PR タイトルのルールについては、references/commit-format.md を参照してください。 check_commit_msg.py はコミットメッセージに関するルールを適用しますが、PR タイトルはチェックされません。メッセージファイル、文字列として指定されたメッセージ、コミット範囲を読み込みますが、タイトルがこのスクリプトを通ることはありません。どちらを書く場合も、このリファレンスを読み込んでください。以下では、どのチェックでも判断できない部分を扱います。

主な type を選ぶ

  1. 主な変更を特定します。
  2. references/gitmoji-mapping.md から対応する gitmoji を選びます。選択時には読み込んでください。
  3. その gitmoji に対応する type を使います。gitmoji や type を独自に作ってはいけません。

よくある組み合わせ：✨ feat、🐛 fix、♻️ refactor、⚡️ perf、📝 docs、✅ test、👷 ci、📦️ build、🔧 chore、⏪️ revert。破壊的変更は type ではありません。💥 は基になる type と ! を組み合わせるため、リリースの分類ではその下にある feat／fix が引き続き読み取られます。

1 つのコミットには、1 つの意味上の変更を記述します。 変更が複数の type にまたがる場合は、リリースノートの見出しにする type を選び、残りは本文の詳細にします。ユーザーへの影響度による優先順位は次のとおりです。

fix > feat > perf > refactor > build > docs > test > chore

付随する編集は数えません。機能のためにテストを追加する機能コミットは ✨ feat です。テストはその機能のために存在するからです。互いに独立した変更が 2 つある場合は、2 つのコミットに分けてください。件名に混ぜず、別々であることを伝えます。

リリースツールが読み取るのは type なので、誤ったラベル付けには代償があります。chore として登録された機能はリリースノートに載らず、feat として登録されたリファクタリングはバージョンを不必要に引き上げます。書くときにどう感じたかではなく、変更が何をするかに基づいて選んでください。

レビュアーではなく git blame のために本文を書く

空でない行を 12 行にするのが目標で、20 行は絶対に超えてはいけません。 フッターとコードフェンスで囲まれたブロックは対象外です。そのため、スタックトレース、失敗する設定、ベンチマーク表など、コミットとともに残す必要がある証拠はフェンス内に記述します。

本文に含める内容：差分からは分からない動機（制約、バグの仕組み、却下した代替案）、読者が予測できない影響、そして省略が見落としに見える場合は、意図的に対応していないこと。

含めない内容：

  • セッションの経過 — 「その後テストを実行したところ、X が見つかった」など。本文がコードの新しい状態ではなく、作者の作業内容を説明しているのが見分けるポイントです。これは PR の説明に記載します。
  • 証拠の羅列 — テスト数、カバレッジ、ミューテーションの集計。PR では最新情報ですが、git log では古くなります。例外：数値そのものが理由である場合（「p99 が 150ms の基準に対して 240ms だった」）。
  • 件名の言い換えや、差分ですでに分かるファイルの列挙。
  • プロセスについての説明 — どのスキルに従ったか、どのパスで見つかったか、何回かかったか。

説明にそれ以上の分量が必要なら、コミット本文ではなく、RFC、issue、PR の説明に記載し、1 行でリンクしてください。また、見出しが必要だったり段落ごとに話題が変わったりする本文は、変更をまとめすぎている兆候です。段落が 6 つあるなら、通常は 6 つのコミットに分けるべきです。これは、実際に見つかった問題よりも主な type のルールを優先するということです。

チェック

python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --message "✨ feat(api): add OAuth login"
python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --range main..HEAD   # audit a branch
python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --file "$1"          # commit-msg hook

本文の上限をここで文章として示すのではなく、スクリプトで適用するのには理由があります。この文章のルールが読まれ、同意されたにもかかわらず、同じセッション内で無視されたために追加されました（drift-to-gate）。

コミットメッセージまたは PR タイトルだけを出力してください。説明や、求められていない代案は出力しないでください。

関連スキル

  • keep-a-changelog — 同じ変更をユーザー向けの CHANGELOG.md の項目にまとめます。ここで破壊的変更を含むコミットを行う場合は、CHANGELOG にも明示的な破壊的変更の項目が必要です。このスキルがなくても、項目を記載してください。失敗なのは破壊的変更の行がないことであり、スキルがないことではありません。

コメント

Markdown 対応