simple-add
必要な範囲を確認してステージングとコミットを行い、pushは指定がある場合だけ実行する。
対象範囲とオプション
| 指定 | コミット対象・操作 |
|---|
-m / --mine、または「あなたが担当した分だけ」 | このタスクで自分が担当した未コミット差分だけ |
| 対象ファイルの指定 | 指定されたパスの変更。--mineもあれば、その中の担当差分だけ |
| 上記の範囲指定なし | 現在の全変更。新規セッションやコンテキスト圧縮後で作業文脈が不足していても同じ |
-p、または自然文での明示的なpush指示 | コミット後にgit pushも実行 |
-mはこのスキルの対象範囲を指定するオプションで、git commit -mのメッセージ指定とは別である。pushの許可は含まない。
dev:simple-add -m # 担当分だけコミット
dev:simple-add -m -p # 担当分だけコミットしてpush
1. 状態と必要な差分を確認する
git status --short
git diff --stat
ファイル一覧と既知の作業内容からコミットメッセージを作る。作業文脈が不足していれば、git diff --statで分かる範囲から要約する。
詳細なgit diffやgit log --oneline -3は標準手順にしない。メッセージの根拠が不足する場合、大きな生成物・秘密情報・意図しない削除が疑われる場合、担当差分の切り分けが必要な場合に限り、関係する差分を追加で読む。文脈から判断できるコミットに、長い調査や分析を挟まない。
2. 対象だけをステージする
範囲指定がなければgit add -Aを使う。対象パスが指定されている場合や、ファイル全体が担当分と分かる場合はgit add -- <pathspec...>を使う。対象外の変更は戻さない。
--mineで担当差分を分ける場合
- 会話中の作業記録・編集内容と現在の差分を照合する。同じファイルを触ったことや、Gitのauthor・更新時刻だけで全差分を担当分とみなさない。
- 別作業の変更が同じファイルにあれば担当hunkだけをステージする。同じhunkにも混在する場合は、担当差分だけのpatchをindexへ適用するなどして分ける。作業ツリーを過去版へ戻したり、他の変更を上書きしたりしない。
- 既にステージ済みの別作業も混ぜない。必要なら一時indexで分離し、他の変更と元のステージ状態を保持する。
- 関連記録と差分を読んでも担当範囲が不明、または変更が不可分なら、その箇所を示して範囲を確認する。全変更への拡大で代用しない。担当する未コミット変更がなければ、その旨を報告する。
ステージ後に、実際にコミットするindexを確認する。一時indexを使った場合も、そのindexに対して確認・コミットする。
git status --short
git diff --cached --stat
必要な場合だけgit diff --cachedを追加で読む。--mineでは担当分だけであることを確認する。秘密情報や意図しない大きな生成物など、危険な差分が疑われる場合はコミット前に止め、利用者へ確認する。
3. コミットし、指定があればpushする
既存リポジトリのメッセージ規約を優先する。規約がなければ、変更に合うtypeとemoji、日本語の要約を使う。
<emoji> <type>: <日本語の要約>
<必要な場合だけ変更の説明>
Co-Authored-By: OpenAI <noreply@openai.com>
本文は任意。件名で十分なら件名とCo-Authored-Byだけにし、小さな変更の説明は1〜2行に留める。形式を埋めるための長い箇条書きは作らない。
| Type | Emoji | 説明 |
|---|
feat | ✨ | 新機能 |
fix | 🐛 | バグ修正 |
docs | 📝 | ドキュメント |
style | 💄 | フォーマット・スタイル |
refactor | ♻️ | リファクタリング |
perf | ⚡️ | パフォーマンス改善 |
test | ✅ | テスト |
chore | 🔧 | ツール・設定 |
ci | 🚀 | CI/CD改善 |
コミット後、push指定があればgit pushを実行する。最後にgit statusを確認し、pushした場合はその成功も確認する。--mineでは対象外の変更が保持されていることを確かめる。作業ツリーを空にするための追加コミットはしない。
4. 結果を報告する
コミットhashと件名、必要な確認結果、pushの実施・未実施を短く示す。
フック経由の場合だけ、直前の作業報告を再掲する
呼出元が<hook_prompt ...>を含む、または「フックからのフィードバック」としてコミットを求めている場合だけ、フック経由とする。通常の明示的なsimple-add依頼では再掲しない。
フック経由では、コミット処理で直前のユーザー向け作業報告がUI上で折りたたまれることを前提にする。最終回答に「先ほどの作業内容(再掲)」を加え、直前に報告した成果・決定、主な変更・設計判断、成果物へのlink、検証結果、未実装事項や次のtaskのうち、文脈にあるものだけを短く言い換える。
直前の回答を全文引用せず、内部の調査過程やcommentaryも再掲しない。コミット差分から未報告の内容を推測して加えない。元の報告を開かなくても成果と次の状態を把握できる長さにし、直前に実質的な作業報告がなければ再掲しない。