Communityコーディング&開発github.com

Marcussyl/cursor-skills

ワーキングツリーを複数のフォーカスされたコミットに分割し、それぞれ関連する変更のみを含めてコミットした後、リモートにプッシュします。ユーザーが /commit-batches を呼び出したり、バッチコミットやトピックごとの分割コミットを要求したときに使用します。

cursor-skills とは?

このスキルは、未コミットの変更を論理的な単位に分割し、複数のコミットとして管理するためのものです。各コミットは独立してレビュー可能で、それぞれの変更に必要なすべてのファイルを含むように設計されています。安全面に配慮し、git configの変更や強制プッシュ、フックのスキップはユーザーが明示的に要求しない限り行いません。また、`.env`などの機密情報をステージングしないように警告します。処理の流れは、まず `git status` や `git diff` で変更を確認し、次に変更を目的別にグループ化して計画をユーザーに提示します。その後、バッチごとにコミットを実行し、最後にリモートにプッシュします。対応プラットフォームは、Git を利用するあらゆる環境(Cursor, Claude Code など)で動作します。

対応~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/Marcussyl/cursor-skills/tree/HEAD/commit-batches

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

バッチでコミットする

未コミットの作業を論理的なコミットに分割します。各コミットは独立してレビュー可能で、そのスライスに必要なすべてのファイルを含んでいる必要があります。

安全対策(常に)

  • git config を更新しないでください。
  • ユーザーが明示的に要求しない限り、強制プッシュ、ハードリセット、その他の破壊的な git 操作は行わないでください。
  • ユーザーが明示的に要求しない限り、フックをスキップしないでください(--no-verify など)。
  • シークレット(.env、認証情報、鍵)をステージングしないでください。警告し、除外します。
  • ユーザーの修正ルールが完全に満たされない限り、git commit --amend を使用しないでください。
  • コミットフックが失敗した場合は、問題を修正して新しいコミットを作成してください。失敗したコミットを修正しないでください。
  • コミットメッセージに Co-authored-by: Cursor を追加しないでください。

1. 調査

可能な場合は並行して実行します:

  • git status
  • git diff および git diff --staged
  • git log -5 --oneline メッセージスタイルの確認用
  • git remote -v およびブランチ追跡(git status -sb)

コミットするものがない場合は、その旨を伝えて停止します。

2. バッチを計画する

変更を目的ごとにグループ化します。ファイルタイプだけに基づかないでください。例:

  • 1つの機能またはユーザー向けの動作とそのテスト、ドキュメント
  • 1つのバグ修正とそれを修正するファイルのみ
  • 独立したリファクタリング(無関係な機能を混在させない)
  • 1つの領域にスコープされた雑務やツール(依存関係、CI、設定)

ルール:

  • 1つのコミットに無関係な機能を混在させないでください。
  • 同じバッチに付随ファイルを含めます(例:1つの変更に対するスキーマ + エンティティ + マイグレーション + 呼び出し箇所)。
  • ファイルが2つの関心事に触れている場合は、主要なバッチを優先するか、コミット前にトレードオフを説明してください。
  • バッチを順番にリストします:基本(共有型、設定)、次に機能、最後にドキュメント(先行コミットに依存する場合のみ)。

ユーザーに簡潔な計画を表示します:バッチ番号、ファイルまたはパス、提案する従来のコミット件名。その後、ユーザーが反対しない限り進めます。

3. 各バッチをコミットする

各バッチに対して、順次:

  1. そのバッチのみをステージングします(git add で特定のパスを指定。ツリー全体が1つのバッチでない限り git add -A は避けます)。
  2. git diff --staged で無関係なものが混入していないか再確認します。
  3. なぜに焦点を当てた従来のコミット件名(feat、fix、chore、docs、refactor、test など)を記述します。
  4. ブランチ名に課題 ID が含まれている場合は、件名に #<issue> を追加します(GitLab スタイル)。
  5. コミットします。Windows PowerShell では git commit -m '件名'(または短い本文のために複数の -m)を使用します。bash では、メッセージに HEREDOC を使用しても構いません。
  6. 対象の変更に対してワーキングツリーがクリーンになるまで繰り返します。

4. GitHub(またはリモート)にプッシュする

すべてのバッチが終わったら:

  • origin(またはユーザーの指定したリモート)が存在し、ブランチを公開すべき場合は、上流がないときは git push -u origin HEAD を実行し、それ以外は git push を実行します。
  • main または master に強制プッシュしないでください。
  • プッシュが拒否された場合は、エラーを報告し、pull/rebase を提案します。ユーザーが明示的に要求しない限り、強制プッシュは行いません。
  • リモートがない場合は、コミットはローカルのみであると伝え、リモートを追加するかどうかを尋ねます。

5. 報告

要約:

  • 各コミットのハッシュと件名(最新を最後に、または番号付きリスト)。
  • プッシュ結果(利用可能な場合は URL またはブランチ)。
  • 意図的にステージングされていないもの(シークレット、ローカル専用ファイル)。

commit-msg との関係

commit-msg はすでにステージングされたファイルから1行を提案するだけで、コミットはしません。このスキルは計画、ステージング、複数ステップでのコミット、プッシュを行います。

関連スキル