high-quality-commit
コード変更を適切なgitコミット戦略でgit commitします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
コード変更を適切なgitコミット戦略でgit commitします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
High Quality Commit
このスキルは、コード変更を高品質なgitコミットとして記録するための包括的なガイダンスを提供します。
Instructions
ステップ1: ブランチとgitコミット履歴の確認
以下のコマンドで現在の状態を確認：
git status
git log --oneline --graph origin/main..HEAD
確認事項：
- 現在のブランチ名
- mainブランチから何gitコミット進んでいるか
- 各gitコミットの内容と粒度
ステップ2: gitコミット戦略の判断
以下の基準でgitコミット戦略を選択：
戦略A: Squash（基本戦略）
以下の条件を満たす場合、既存のgitコミットにsquashします：
- ブランチに既にgitコミットが存在する
- 変更内容が既存のgitコミットと同じテーマ・機能に関連している
- gitコミットを分ける合理的な理由がない
実行方法：
git add -A
git commit --amend
gitコミットメッセージを適切に更新してください。
戦略B: 新規gitコミット
以下の場合は新規gitコミットを作成：
- ブランチに初めてのgitコミット
- 既存のgitコミットとは異なる独立した変更
- gitコミットを分けることで履歴がより理解しやすくなる
実行方法：
git add -A
git commit
戦略C: Interactive Rebase（gitコミット再構成）
以下の場合はブランチ全体のgitコミットを再構成：
- 複数の小さなgitコミットを論理的なまとまりに整理したい
- gitコミットの順序を変更したい
- 不要なgitコミットを削除したい
- gitコミット履歴を意味のある単位に再編成したい
実行方法：
git rebase -i origin/main
エディタで以下の操作を実行：
pick: gitコミットをそのまま維持squashまたはs: 前のgitコミットと統合rewordまたはr: gitコミットメッセージを変更- 行の順序を変更してgitコミット順を変更
ステップ3: gitコミットメッセージのガイドライン
gitコミットメッセージは以下の形式で記述：
<type>: <subject>
<body>
<footer>
Type:
feat: 新機能fix: バグ修正refactor: リファクタリングtest: テスト追加・修正docs: ドキュメント変更chore: ビルドプロセスやツールの変更
Subject:
- 50文字以内
- 命令形で記述（例: "add"ではなく"Add"）
- 末尾にピリオドを付けない
Body（オプション）:
- 変更の理由と背景を説明
- 何を変更したかではなく、なぜ変更したかを記述
- 72文字で折り返す
Footer（オプション）:
- Issue番号への参照（例:
Closes #123） - Breaking changesの記述
ステップ4: git commit後の確認
git commit後、以下を確認：
git log -1 --stat
git status
- gitコミットが正しく作成されたか
- 意図したファイルがすべて含まれているか
- gitコミットメッセージが適切か
重要な注意事項
- mainブランチでは実行しない: mainブランチで直接git commitしないでください
- コメントは残さない: コード内の説明コメントは削除してください
- 原子的なgitコミット: 各gitコミットは独立して意味を持つようにしてください
- 一貫性: プロジェクトの既存のgitコミットスタイルに従ってください
戦略選択のフローチャート
ブランチにgitコミットがある？
├─ No → 新規gitコミット作成
└─ Yes → 変更は既存のgitコミットと同じテーマ？
├─ Yes → Squash（git commit --amend）
└─ No → gitコミットを分ける合理性がある？
├─ Yes → 新規gitコミット作成
└─ 履歴を整理したい → Interactive Rebase
You Might Also Like
Related Skills
create-pr
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
n8n-io
electron-chromium-upgrade
Guide for performing Chromium version upgrades in the Electron project. Use when working on the roller/chromium/main branch to fix patch conflicts during `e sync --3`. Covers the patch application workflow, conflict resolution, analyzing upstream Chromium changes, and proper commit formatting for patch fixes.
electron
pr-creator
Use this skill when asked to create a pull request (PR). It ensures all PRs follow the repository's established templates and standards.
google-gemini
clawdhub
Use the ClawdHub CLI to search, install, update, and publish agent skills from clawdhub.com. Use when you need to fetch new skills on the fly, sync installed skills to latest or a specific version, or publish new/updated skill folders with the npm-installed clawdhub CLI.
moltbottmux
Remote-control tmux sessions for interactive CLIs by sending keystrokes and scraping pane output.
moltbot
create-pull-request
Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, and PR creation using the gh CLI tool.
cline