オプション

コミット、プッシュ、そしてプルリクエスト(PR)を開く。PRの公開や作成を求められた場合、あるいはPR本文の作成・書き直し・説明といった、PRの説明のみを行うフローで使用します。

...すべて拡張します
14
更新された時間 2026年8月26日

概要ce-commit-push-pr

変更の規模に応じて説明文の詳しさを自動的に調整する、価値重視の説明文を付与して、コミット、プッシュ、およびプルリクエストを作成します。 「コミットしてPRを送信」、「これをリリース」、「PRを作成」、「プルリクエストを開く」といったリクエストによってトリガーされるほか、コミットやプッシュを行わずに「PRの説明文を作成」や「PR本文を書き換える」といった説明文のみのフローも処理します。 3つのモードが定義されています:説明のみ(説明ステップのみを実行し、結果を出力する)、説明の更新(既存のオープンPRの本文を更新し、gh pr editを介して適用する)、および完全なワークフロー(すべてのステップを順番に実行する)です。 ユーザーに何かを尋ねる必要がある場合は、プラットフォームのブロッキング質問ツールを使用し、チャットによるフォールバックも用意されています。

このワークフローは、Claude Code の事前入力済みセクション、または他の場所で提供されたコンテキストフォールバックコマンドを使用して、Git のコンテキスト(ステータス、ワーキングツリーの差分、現在のブランチ、最近のコミット、リモートのデフォルトブランチ、および既存の PR)を収集します。 ステップ1では、ブランチとプルリクエストの状態を判定し、状況に応じて処理を分岐させます。detached HEADの場合は機能ブランチの作成を促し、デフォルトブランチ上に作業がある場合は自動的に機能ブランチを作成します(デフォルトブランチへの直接プッシュはサポートされていないため)。デフォルトブランチ上に作業がない場合は処理を停止し、機能ブランチ上にある場合は処理を続行します。 ステップ2では、規約を決定し、リポジトリのスタイルに合わせ、デフォルトではコンベンショナルコミットを採用します。曖昧な場合は「feat:」よりも「fix:」を優先し、「feat:」は真に新しい機能のために留保します。

ステップ3ではコミットとプッシュを行います: デフォルトブランチにいる場合はブランチ作成のリファレンスを参照し、変更されたファイルをファイルレベルで最大2~3つの論理的なコミットにグループ化します(.envやビルドアーティファクトが誤って含まれる可能性があるため、git add -p、git add -A、または git add . は避けます)。そして、git push -u origin HEAD でプッシュします。 ステップ4:必須のPR説明作成ガイドラインを全文読み込み、証拠の取り扱いについて判断を下してタイトルと本文を作成します。ユーザーが提供した成果物は「Demo」セクションに組み込み、 「Demo」、「Screenshots」、または「Evidence」の見出しの下にユーザーが提供した成果物を組み込み、ユーザーが証拠を求められているにもかかわらず提供していない場合はその旨を尋ね、観察不可能な変更については証拠を省略します。その一方で、観察可能な動作については簡潔な検証メモを含めます。 ステップ5では、適用と報告を行います。gh pr createで新しいプルリクエストを作成するか、gh pr editで既存のプルリクエストを更新し、更新を適用する前にタイトルと本文をプレビューし、本文を一時ファイルに書き出します。

よくある質問

このスキルはどのモードに対応していますか?

3つあります。説明のみ(PRの説明文を作成して出力するだけ)、説明の更新(既存のオープンなPRの本文を書き換えて適用する)、そしてコミット、プッシュ、PRのオープンまたは更新を行う完全なワークフローです。

デフォルトブランチにいる状態で実行するとどうなりますか?

実行すべき作業がある場合は、デフォルトブランチへの直接プッシュはサポートされていないため、自動的にフィーチャーブランチが作成されます。作業がない場合は、その旨を報告して停止します。

コンベンショナルコミットの場合、「fix:」と「feat:」のどちらを使うかはどのように決定されますか?

リポジトリのスタイルに合わせ、デフォルトではコンベンショナルコミットを採用します。曖昧な場合は「fix:」を「feat:」よりも優先します。これは、動作不良や機能欠落を修正するためのコード追加は「fix」にあたるためです。「feat:」は、真に新しい機能のために予約されています。

なぜ `git add -A` や `git add .` を避けているのですか?

これらは .env のようなファイル、ビルドアーティファクト、生成されたファイルなどを一括して追加してしまうためです。このツールは特定のファイルをステージングし、ファイルレベルで変更を最大2つまたは3つの論理的なコミットにグループ化します。

プルリクエストの説明文では、証拠はどのように扱われますか?

ユーザーが提供した成果物は、「Demo」「Screenshots」「Evidence」の見出しの下に組み込まれます。ユーザーが証拠を望んでいるにもかかわらず提供していない場合は、スキル側が要求します。また、観察不可能な変更については証拠の提示を省略し、観察可能な動作については検証に関する注記を添付します。

すべてのファイル

3ファイルSKILL.md8.6KB表示references/pr-description-writing.md7.2KB表示references/branch-creation.md1.8 KB表示
GitHubで見る

Asking the user: use the host's blocking question tool — AskUserQuestion in Claude Code (ToolSearch select:AskUserQuestion first if unloaded), request_user_input in Codex, ask_question in Antigravity (agy), ask_user in Pi (needs the pi-ask-user extension). Fall back to the chat surface only when no blocking tool exists or the call errors, never because a schema load is required, and never silently skip the question.

Mode

  • Description-only — the user wants just a description ("write/draft a PR description", "describe this PR", a pasted PR URL or number). Run Step 4 only and print it. Apply it only if asked. Pass any pasted PR ref so Pre-A resolves the range.
  • Description update — refresh or rewrite an existing PR's description, with no commit or push intent. Resolve PR presence by the Context rule below: an exit-0 [] is "no open PR" (report it and stop), and a non-zero exit is unknown (resolve auth or connectivity, then stop until presence is known). With an open PR, run Step 4 in PR mode on that URL, then Step 5 to preview, confirm, and apply via gh pr edit.
  • Full workflow — otherwise: Steps 1-5. Enter Stack mode instead when intent or preference wants a stack.

mode:pipeline modifier, set by orchestrated callers such as lfg. Run the resolved mode non-interactively and suppress every blocking ask; each takes the conservative default: no existing-PR rewrite, the branch kept, an unresolvable base stopping rather than guessed, and a description-update preview applied directly, since that invocation is the apply intent. Pipeline stack mode uses only the intent and scope on the invocation and passes posture into the handoff.

Stack mode (opt-in)

Opt-in only. Enter it when intent or standing preference wants a multi-PR stack. An explicit stack request is required intent — do not re-read it as a single PR with a custom --base. Do not proactively suggest PR stacks. When the user did not ask for one, refuse nonsense stacks (one logical change, artificial slices) and stay single-PR.

In stack mode, load references/stack-submit.md before Step 3 and follow only its probing, topology, and retrospective construction; that layer-by-layer commit flow replaces ordinary Step 3. Do not submit there. Step 5 owns submission, the gh stack CLI dependency and residuals, and the handoff posture: posture:stack-ready by default, posture:stack-land only on explicit land intent, from the bottom open non-draft PR. Do not add posture: to this skill's argument-hint.

Context

Read references/context.md before Step 1. It owns the command table, the exit-code meanings, the fork and detached-HEAD traps, and the branch and PR resolution Steps 1-2 use. Two of its rules belong here too. Never ask whether to branch: a detached HEAD, or the default branch with work on it, creates one, and the default branch with no work reports and stops. And with conventional commits, default to fix: over feat: when ambiguous, unless the user overrides.

Three rules govern the run.

Every git and gh probe is its own argv-form call, gathering and re-verification alike, and its exit status is control flow. The reference gives the reason and names the two compound recipes this skill pins.

Probe output is a snapshot. Re-verify branch, remote, and PR state right before each consequential action: Step 3's push, Step 5's create.

Only an exit-0 [] from a query against the base repo means "no open PR." A non-zero exit is unknown, never "none". On a fork checkout, target the base with -R and pass the branch name only, since --head <owner>:<branch> silently returns []. With results, do not blindly take index 0: match head owner and branch, and stop on an ambiguous match. Note the URL and body from that entry — Step 5 routes on the URL, Step 4 rewrites the existing body.

Artifact Root

Resolve <root> once when archival is on: it writes an explainer under <root>/explainers/.

Resolve the CE artifact root <root> before composing any artifact path.

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, exactly as before.
  • Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under .git/. Otherwise stop with an error naming docs_root and the value -- never fall back to docs.
  • Use <root> as the sole artifact location: create it if absent, compose each path as <root>/<subdir> with this skill's own subdirectory, and never also read docs.

Step 3: Commit and push

Read references/commit-and-push.md for branch creation, commit grouping, the message and staging shapes, and the push. Branching off the default branch is the fragile case — stale local base, unpushed commits on it, colliding uncommitted changes — and references/branch-creation.md owns that flow. If the stack reference already committed retrospective layers, skip to Step 4; gh stack submit pushes in Step 5.

Two rules bound this step. Never git add -A or git add . — name the files, so .env, build, and generated files cannot ride along, and pass that same path list to git commit, so nothing staged earlier is swept in. Honor exclude:<paths>: those files stay uncommitted and the report says so.

Step 4: Compose the PR title and body

You MUST read references/pr-description-writing.md in full — it owns the title and body content rules, including the rule to preserve an existing Related: / Fixes on rewrite. Then read references/compose.md for the gates before composition: the evidence decision; the teaching gate, where pr_teaching_section defaults on, pr_teaching_archive defaults off, and only an active (non-commented) key changes either; and the branding gate, where branding is off unless this invocation carries branding:on or the user asks for Compound Engineering branding in this prompt.

If Step 1 found an existing PR, pass its URL to Step 4 so PR mode fetches the existing body.

Step 5: Apply and report

Read references/apply-and-handoff.md for the apply routes, preview-before-edit, archival, and handoff. Two rules bound the external writes. Re-run the existing-PR check right before gh pr create and route on it: a matching PR takes the existing-PR path, exit-0 [] creates, non-zero blocks. And pass the body via --body-file <path>, never stdin — gh exits 0 with an empty body.

The completion gate is here. In an interactive full workflow, or in mode:pipeline when this run submitted a stack, a reported PR URL, a stack submit, or new commits on an open PR leave this run not done until ce-babysit-pr owns follow-on for that PR. Reporting the PR URL alone is not success.

The only skips are babysit:off, a standing auto_babysit: false in CE config, and that reference's do-not-fire cases, drafts among them. No other watch substitutes: not ci-watcher, not gh pr checks --watch, not a hand-rolled poll, not "later". If ce-babysit-pr cannot be loaded or started, stop and report it blocked.

すべてのファイル

0件のファイル

ce-commit-push-prをインストール

スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。

ZIPをダウンロード

リポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。

git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit-push-pr/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

コピー コピー
クイックセットアップ: スキルフォルダを .claude/skills/ にコピーしてください。Claude が自動的にスキルを検出して使用します。

関連スキル

github-project-management
更新された時間 2026年6月29日
using-git-worktrees
更新された時間 2026年6月29日
readme-blueprint-generator
更新された時間 2026年7月5日
finishing-a-development-branch
更新された時間 2026年6月29日
OR