commit-summary

コミットの概要

実際の Git 差分から、正確な Conventional Commits を生成します。

許可された範囲

ユーザーの依頼と既存の承認の範囲内でのみ作業してください。このスキルを読み込んでも、新たな権限は付与されません。報告のみの依頼は報告のみとして扱い、依頼者が指定した対象、ホスト、プロバイダー、コスト上限を守り、範囲を広げる前に確認し、これらの制限を委任先にも伝えてください。

契約

入力：

• リポジトリのルート
• ステージ済みの変更、未ステージの変更、またはステージすることが承認されたパス
• 任意のコミット種別、スコープ、破壊的変更に関する背景情報

出力：

• コミットメッセージ候補
• 変更が混在している場合の論理的なコミット分け
• 依頼された場合、承認後に作成したコミットハッシュ

作成／変更：

• メッセージのみのモードでは変更なし
• 承認後、ファイルのステージングやコミットの作成を行う場合があります

外部への副作用：

• 後続の別ワークフローでコミットがプッシュされない限り、ありません

確認が必要な操作：

• ファイルをステージする前
• コミットを作成する前
• 既存のコミットを修正またはスカッシュする前

委任先：

• コミットをプッシュして PR を作成する場合は github-pr-publish
• 差分にシークレットや機密ファイルが含まれる場合は git-safety

ワークフロー

1. リポジトリの状態を確認します：

   git status -sb
   git log --oneline -5
   git diff --stat
   git diff --cached --stat
   

2. 変更がすでにステージされているかを確認します：

   • ステージ済みの変更がある場合は、git diff --staged からメッセージを生成します。
   • ステージ済みの変更がない場合は、未ステージの変更を調べ、論理的なグループを提案します。
   • 無関係な変更が混在している場合は、コミットを分けることを推奨します。

3. 安全でないコミットを防ぎます：

   • シークレット、.env、認証情報、秘密鍵、ローカルデータベース、ビルドキャッシュ、大きな生成アーティファクトをステージしないでください。
   • 機密ファイルが含まれている場合は作業を中断し、git-safety に委任します。
   • 変更に必要でない限り、機能追加／修正のコミットに無関係なフォーマット変更を含めないでください。

4. Conventional Commit の種別を選びます：

   • feat：ユーザー向けの機能または能力
   • fix：バグ修正
   • docs：ドキュメントのみ
   • style：動作を変更しないフォーマットのみの変更
   • refactor：動作を変更しないコードの再構成
   • perf：パフォーマンスの改善
   • test：テストのみ
   • build：ビルドシステム、パッケージマネージャー、依存関係
   • ci：CI/CD ワークフローの変更
   • chore：ユーザー向けの動作を伴わない保守作業
   • revert：以前のコミットの取り消し

5. スコープを特定します：

   • 履歴ですでに使われているパッケージ、アプリ、ドメイン、サブシステムの名前を優先します。
   • 曖昧になる場合（misc、stuff、changes）はスコープを省略します。

6. 破壊的変更を検出します：

   • 公開 API の契約変更
   • CLI のフラグまたは出力の変更
   • ユーザーによる対応が必要なデータベース／スキーマのマイグレーション
   • 設定キー、環境変数、ルート、イベント、エクスポートされたシンボルの削除

   type(scope)!: summary の形式にし、BREAKING CHANGE: フッターを含めます。

7. コミットメッセージを生成します：

   type(scope): imperative summary
   
   Optional body explaining why and any non-obvious implementation detail.
   
   Optional footer such as:
   BREAKING CHANGE: migration required because ...
   Refs: #123
   

8. ユーザーがコミットを依頼している場合は、正確なメッセージを提示し、その承認の範囲内で実行します。選択したファイルや操作が依頼の範囲を超える場合に限り、承認を得てください：

   git add <approved-paths>
   git diff --staged --stat
   git commit -m "<subject>" -m "<body-or-footer>"
   

品質基準

• 件名は命令形で、72 文字未満にします。
• 差分だけでは不十分な場合は、本文で理由を説明します。
• メッセージで動作を誇張しません。
• コミットには論理的にまとまった変更を 1 つ含めます。
• リポジトリの慣例で求められていない限り、検証コマンドをコミットメッセージに含めません。

注意点

• git add . は意図しないファイルをステージングする可能性があります。 .gitignore で node_modules、.env*、またはビルド成果物が除外されていない場合は、常に git add <specific-paths> を優先してください。コミット前に git diff --staged --stat で確認してください。
• 破壊的変更を示すフッターは大文字と小文字が区別されます。 semantic-release や conventional-changelog などのツールが検出するには、トークンが正確に BREAKING CHANGE:（スペースを含み、すべて大文字）である必要があります。BREAKING-CHANGE: は同じ意味ではありません。
• コミットの amend は履歴を書き換えます。 共有ブランチにすでにプッシュされたコミットは、決して amend しないでください。リモートにコミットが存在する場合は、代わりに新しい修正コミットを作成してください。
• Co-authored-by トレーラーはリポジトリの規約に反する場合があります。 このプロジェクトを含む一部のリポジトリでは、Co-Authored-By トレーラーを明示的に禁止しています。追加する前に、リポジトリのエージェント指示ファイル（AGENTS.md、CLAUDE.md など）または最近のコミット履歴で、プロジェクトの規約を確認してください。

例

• feat(auth): add password reset flow
• fix(api): handle null provider response
• ci(actions): restrict pull request token permissions
• refactor(utils): extract date formatting helper
• docs: update GitHub project board workflow