mcpField
G
git-commit

git-commit

github.com/fan-s-collective開発1246 回インストール26 週間前に更新
リポジトリ

git-commit について

リポジトリの変更内容に基づいてGitコミットメッセージを作成するスキルです。差分やリポジトリ内の規約、直近の履歴を確認してから、種類、スコープ、言語を選びます。

主な機能

  1. 01ステージ済み・未ステージの差分確認
  2. 02リポジトリのコミット規約の確認
  3. 03直近のコミット言語への準拠
  4. 04コミットの種類とスコープの選択
  5. 05必要に応じた本文の追加

活用シーン

  1. 01確認済みの変更にコミットメッセージを作成
  2. 02プロジェクト規約に沿ったヘッダーの調整
  3. 03分割すべき複合変更の特定

インストール

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

$npx skills add https://github.com/fan-s-collective/git-commit-skills --skill git-commit

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

同梱ファイルagents/openai.yamlSKILL-CN.md

詳細

Git Commit

概要

実際のリポジトリの変更内容に基づいてコミットメッセージを作成します。ファイルごとの差分の要約よりも、簡潔で変更の意図を重視したメッセージを優先します。references/commit-convention.md を基本のスタイルガイドとして、現在のリポジトリに合わせてスコープや表現を調整します。

ワークフロー

  1. まず変更内容を確認します。

    • ステージ済みの変更がある場合は、git diff --staged を優先します。
    • ステージ済みの差分がない場合、またはユーザーが未ステージの変更について尋ねている場合は、git diff を使用します。
    • git status --short でファイルの範囲を確認します。
    • リポジトリにコミット規約ファイルがある場合は、メッセージを書く前に読みます。COMMIT_CONVENTION.md、CONTRIBUTING.md、.github/COMMIT_CONVENTION.md、.github/CONTRIBUTING.md などの一般的なファイル名を確認します。
    • git log --format=%s -n 20 で最近のコミットの件名を調べ、リポジトリで優先されている出力言語を推測します。履歴で最も多く使われている言語に従います。最近のコミット件名が複数の言語で、明確に優勢な言語がない場合、コミット履歴がない場合、またはその他のエラーで確認できない場合は、英語を既定とします。

  2. コミットの意図を1つ選びます。

    • 変更に互いに無関係な意図が含まれる場合は、コミットを分けることを推奨します。
    • ユーザーがそれでも1つのメッセージを希望する場合は、主な意図を選び、トレードオフを簡潔に説明します。

  3. ヘッダーを選びます。

<type>(<scope>): <subject>
  1. 意図、影響、互換性、移行、または複数の変更種別を明確にする場合にのみ本文を追加します。

種別の選択

  • feat：新機能
  • fix：バグや不具合の修正
  • perf：パフォーマンスの改善
  • refactor：外部の動作を変えずに実装を再構成
  • style：書式やコードスタイルのみの変更
  • test：テストの追加や調整
  • docs：ドキュメントやコメント
  • chore：依存関係、ビルド、ひな型作成、その他のメンテナンス
  • ci：CI の変更
  • types：型定義の変更
  • revert：既存のコミットの取り消し
  • wip：一時的な作業中コミット

変更種別が複数ある場合は、コミットを分けるか、ヘッダーには主な種別を使い、本文の箇条書きには種別のプレフィックスを付けます。

スコープの選択

現在のリポジトリから scope を導きます。実際に変更されたパスやローカルの規約に一致しない限り、参照ファイルのスコープを再利用しないでください。

次の優先順位に従います。

  1. リポジトリ独自のコミット規約で明示されているスコープを使います。
  2. 変更されたパスから、api、web、cli、core、ui、docs などの安定したワークスペース、パッケージ、アプリ、モジュール名を使います。
  3. 変更が明らかに特定のサブモジュールに集中しており、その名前が今後も再利用できる場合に限り、より具体的で長期的に使えるサブモジュール名を使います。
  4. リポジトリ全体に関わる変更、複数領域にまたがる変更、または1つのモジュールに絞れない変更には repo を使います。

リポジトリの規約で意味のあるスコープが必要とされていない場合は、ローカルのスタイルで許可されているときに限り、省略します。

件名と本文

件名には変更の中心的な意図を書きます。短く、具体的で、行動が伝わる表現にします。update、fix bug、optimize code のような曖昧な件名は避けます。

出力言語は、リポジトリの最近のコミット履歴に合わせます。明確に優勢な言語がある場合はそれを使います。最近の履歴に一貫性がない、または複数の言語が混在している場合、コミット履歴がない場合、あるいは確認に失敗した場合は、既定で英語のコミットメッセージを作成します。

必要に応じて本文を書きます。

  • 意図、影響、必要な背景を説明します。
  • 変更したファイルを1つずつ言い換えるのは避けます。
  • すべての箇条書きが同じ変更種別の場合は、各項目で種別を繰り返しません。
  • 変更種別が混在する場合は、本文の箇条書きに type: のプレフィックスを付けます。

例：

feat(auth): add session refresh flow

- 增加会话刷新入口，减少登录态过期后的重复认证
- 补齐旧 token 兼容逻辑，避免升级后状态丢失

refactor: align release workflow

- refactor: 收敛构建与发布脚本的职责边界
- fix: 修正缺少版本号时的默认值异常
- docs: 补充新的发布流程说明

参考資料

基本となる Conventional Commits のルールと例については、references/commit-convention.md を読みます。スコープの例は、現在のリポジトリの構成に合わせて変更します。

コメント

Markdown 対応