writing-commit-messages について
開発者やチーム向けに、コミットメッセージの形式、タイプ接頭辞、簡潔な件名や本文の書き方を定めるスキルです。
主な機能
- 01タイプとスコープの形式
- 02件名の長さと表記ルール
- 03本文とフッターの利用指針
- 04破壊的変更の記載規則
- 05コミット時期と分割の指針
活用シーン
- 01機能追加や修正の内容を明確に記述
- 02破壊的変更や課題番号の記録
- 03各コミットを単一の変更に整理
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/writing-commit-messagesを入力して読み込まれたか確認します。
詳細
コミットメッセージの書き方
人と機械の両方にとって役立つコミットメッセージを書きましょう。
フォーマット
<type>(<optional scope>): <subject>
<optional body>
<optional footer>
件名のルール
- 件名は 50 文字以内
- 命令形を使います。「added feature」や「adding feature」ではなく「add feature」
- 種別の接頭辞の後の最初の文字は大文字にしません
- 末尾にピリオドを付けません
種別
| 種別 | 使用するタイミング |
|---|---|
feat | ユーザー向けの新機能 |
fix | バグ修正 |
refactor | 動作を変えないコードの再構成 |
docs | ドキュメントの変更 |
test | テストの追加または更新 |
chore | ビルド、CI、ツール、依存関係 |
perf | パフォーマンスの改善 |
style | 書式や空白の変更（CSS を除く） |
ci | CI/CD パイプラインの変更 |
revert | 以前のコミットの取り消し |
スコープ（任意）
影響を受けるコードベースの領域：
feat(auth): add OAuth2 login flowfix(api): handle null response from payments endpointrefactor(db): extract query builder into module
本文（必要に応じて）
何をしたかではなく、なぜ行ったのかを説明します（何をしたかは差分を見ればわかります）。
fix(checkout): prevent duplicate order submissions
The submit button was not disabled after the first click,
allowing users to create multiple orders. This caused
duplicate charges in Stripe.
フッター（必要に応じて）
BREAKING CHANGE: rename `getUserById` to `findUser`
Closes #456
Co-authored-by: Name <email>
例
良い例：
feat(dashboard): add real-time notification bell
fix: resolve race condition in WebSocket reconnect
refactor(api): consolidate error handling middleware
test: add integration tests for payment webhook
chore: upgrade TypeScript to 5.4
悪い例：
fixed stuff
WIP
update
changes
asdf
コミットするタイミング
- 各コミットは、1 つの論理的な変更を表すようにします
- 同じコミットにリファクタリングと機能開発を混在させないでください
- 動作が不完全なコードはコミットしないでください（代わりに
git stashを使います） - 機能ブランチでは早めに、こまめにコミットし、必要に応じてマージ前にスカッシュします
破壊的変更
コミットで破壊的変更を導入する場合：
- 種別の後に
!を追加します：feat(api)!: change auth token format - フッターに
BREAKING CHANGE:を追加し、移行手順を記載します
コメント
Markdown 対応