メニュー
コード変更を適切なgitコミット戦略でgit commitし、pushします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | commit-push |
| description | コード変更を適切なgitコミット戦略でgit commitし、pushします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。 |
| model | sonnet |
| effort | medium |
| context | fork |
このスキルが呼び出された時点で commit と push の実行依頼は既に確定しています。ユーザーへの挨拶・自己紹介・「何を手伝いますか」のような確認質問は一切禁止。ステップ1（git status と git log の確認）から即座に実行を開始してください。
ユーザーから追加の指示や引数は渡されません。デフォルトブランチからの差分・作業ツリーの状態を自分で確認し、Instructions に従って戦略を選択・実行します。基本は既存gitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。
本スキルは単独でも他スキル（exec-issue / fix-review-point / create-pr 等）からの委譲でも起動される。いずれのケースでも、呼び出し元が用意した作業コンテキストを尊重するため、現在地を変更しない・新規worktreeを作らないことを徹底する。
pwd
判定:
.claude/worktrees/ 配下にいる場合: そのworktree内で全ての作業（git status / git commit / git push 等）を完結させる。cdでworktreeの外やリポジトリのルートに移動しない。新規worktreeも作らない.claude/worktrees/ 配下にいない場合（リポジトリのルート・通常のクローン等）: その場で作業する。.claude/worktrees/ 配下への移動や新規worktree作成はしない理由: 本スキルは context: fork のサブエージェントとして起動される場合、親エージェントと同じ作業ディレクトリで実行される。親がworktree内で作業していたなら、そのworktreeでcommit/pushを完結させる必要がある。作業ディレクトリを勝手に動かすと、親の期待する変更対象と実際にcommitされる変更対象がずれ、リモートに誤った差分がpushされる。
本スキルはデフォルトブランチ上でも実行でき、その場合はデフォルトブランチへ直接commit / pushする。ただし公開済みのデフォルトブランチ履歴を壊さないよう、デフォルトブランチ上では新規コミットの追加とforce無しのfast-forward pushに限定する（既pushコミットの --amend / interactive rebase / force push はしない）。ステップ1で現在ブランチがデフォルトブランチかどうかを判定し、以降のコミット戦略とpush方法を切り替える。
git status
DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
# DEFAULT_BRANCH が正常に取得できた場合のみ git log を実行
if [ -n "${DEFAULT_BRANCH}" ]; then
git log --oneline --graph "origin/${DEFAULT_BRANCH}..HEAD"
fi
確認事項: 現在のブランチ名／デフォルトブランチから何gitコミット進んでいるか（DEFAULT_BRANCH取得成功時）／各gitコミットの内容と粒度
取得した CURRENT_BRANCH と DEFAULT_BRANCH から、以降のモードを決める:
CURRENT_BRANCH と DEFAULT_BRANCH が一致する場合、または DEFAULT_BRANCH の取得に失敗した場合）: デフォルトブランチ上での作業とみなす。公開済み履歴を壊さないため、ステップ2では戦略B（新規gitコミット）のみを採用し（--amend＝戦略A・interactive rebase＝戦略Cは使わない）、ステップ5ではforce無しのfast-forward push（git push origin HEAD）を使う。取得失敗時もこのモードへ倒すのは、判定できない状態で force push してデフォルトブランチ履歴を壊す事故を避けるため（fail-safe。取得失敗時は git log の差分確認はスキップしてよい）。DEFAULT_BRANCH も取得できている場合）: feature branch上での作業とみなす。ステップ2の戦略A/B/Cすべてを選べ、ステップ5は --force-with-lease 付きpushを使う。デフォルトブランチモードでは戦略Bのみを使う。デフォルトブランチの履歴は既にリモートへ公開されており、
--amend（戦略A）や interactive rebase（戦略C）で書き換えると他のクローン・CI・オープン中のPRと齟齬が出るため。デフォルトブランチ上の変更は常に新規コミットとして積む。以下の戦略A/Cは通常モード（feature branch）でのみ選択できる。
以下を満たす場合、既存のgitコミットにsquashする: ブランチに既にgitコミットが存在し、変更内容が既存のgitコミットと同じテーマ・機能に関連し、gitコミットを分ける合理的な理由がない。
git add -A
git commit --amend
gitコミットメッセージを適切に更新すること。
以下の場合は新規gitコミットを作成: ブランチに初めてのgitコミット／既存のgitコミットとは異なる独立した変更／gitコミットを分けることで履歴がより理解しやすくなる。
git add -A
git commit
以下の場合はブランチ全体を再構成: 複数の小さなgitコミットの論理的な整理／順序変更／不要なgitコミットの削除／意味のある単位への再編成。
git rebase -i "origin/$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)"
エディタでの操作: pick=そのまま維持／squash（s）=前のgitコミットと統合／reword（r）=メッセージ変更／行の順序変更=gitコミット順の変更
<type>: <subject>
<body>
<footer>
feat（新機能）/ fix（バグ修正）/ refactor（リファクタリング）/ test（テスト追加・修正）/ docs（ドキュメント変更）/ chore（ビルドプロセスやツールの変更）Closes #123）、Breaking changesの記述git log -1 --stat
git status
gitコミットが正しく作成されたか／意図したファイルがすべて含まれているか／メッセージが適切か
ステップ1で判定したモードに応じてpush方法を分ける。
--force-with-lease を使う。git push origin HEAD --force-with-lease
--force / --force-with-lease を使うと公開履歴を巻き戻す事故につながるため絶対に付けない。git push origin HEAD
デフォルトブランチモードのpushがnon-fast-forwardで弾かれた場合は、リモートに未取得のコミットがある状態。force pushで押し込まず、git fetch してから git log origin/${DEFAULT_BRANCH}..HEAD と git log HEAD..origin/${DEFAULT_BRANCH} で差分を確認し、追従（git pull --ff-only など）してから再pushする。
--amend（戦略A）・interactive rebase（戦略C）・force pushはしない（ステップ1のモード判定に従う）デフォルトブランチにいる？（DEFAULT_BRANCH 取得失敗も Yes 扱い）
├─ Yes（デフォルトブランチモード）→ 新規gitコミットのみ作成 → force無しでpush（fast-forward）
└─ No（feature branch / 通常モード）→ ↓
ブランチにgitコミットがある？
├─ No → 新規gitコミット作成 → --force-with-lease でpush
└─ Yes → 変更は既存のgitコミットと同じテーマ？
├─ Yes → Squash（git commit --amend）→ --force-with-lease でpush
└─ No → gitコミットを分ける合理性がある？
├─ Yes → 新規gitコミット作成 → --force-with-lease でpush
└─ 履歴を整理したい → Interactive Rebase → --force-with-lease でpush
Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Execute tasks based on GitHub Issue content