ce-commit-push-pr
everyinc/compound-engineering-plugin
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
...Expand allAbout ce-commit-push-pr
Commits, pushes, and opens a pull request with an adaptive, value-first description that scales in depth with the size of the change. It is triggered by requests like 'commit and PR', 'ship this', 'create a PR', or 'open a pull request', and also handles description-only flows such as 'write a PR description' or 'rewrite the PR body' without committing or pushing. It defines three modes: description-only (run only the description step and print the result), description update (refresh an existing open PR's body and apply via gh pr edit), and the full workflow (run all steps in order). When it needs to ask the user something, it uses the platform's blocking question tool with a chat fallback.
The workflow gathers git context - status, working-tree diff, current branch, recent commits, the remote default branch, and any existing PR - using pre-populated sections in Claude Code or a provided context fallback command elsewhere. Step 1 resolves branch and PR state and routes by situation: a detached HEAD prompts to create a feature branch, being on the default branch with work automatically creates a feature branch (since pushing the default directly is unsupported), being on the default with no work stops, and a feature branch continues. Step 2 determines conventions, matching repo style and defaulting to conventional commits, where it favors 'fix:' over 'feat:' when ambiguous and reserves 'feat:' for genuinely new capabilities.
Step 3 commits and pushes: it consults a branch-creation reference when on the default branch, groups changed files into at most two or three logical commits at the file level (avoiding git add -p and git add -A or git add ., which can sweep in .env and build artifacts), and pushes with git push -u origin HEAD. Step 4 composes the title and body by reading a required PR-description-writing reference in full and making an evidence decision - incorporating user-supplied artifacts under Demo, Screenshots, or Evidence headings, asking when the user wants evidence but has not supplied it, and skipping evidence for non-observable changes - while including a concise validation note for observable behavior. Step 5 applies and reports, creating a new PR with gh pr create or updating an existing one with gh pr edit, previewing the title and body before applying an update, and writing the body to a temp file.
FAQ
What modes does this skill support?
Three: description-only (just write and print a PR description), description update (rewrite an existing open PR's body and apply it), and the full workflow that commits, pushes, and opens or updates a PR.
What happens if I run it while on the default branch?
If there is work to do it automatically creates a feature branch, because pushing the default branch directly is not supported. If there is no work, it reports that and stops.
How does it decide between fix: and feat: for conventional commits?
It matches repo style and defaults to conventional commits, favoring 'fix:' over 'feat:' when ambiguous, since adding code to remedy broken or missing behavior is a fix. 'feat:' is reserved for genuinely new capabilities.
Why does it avoid git add -A and git add .?
Because those sweep in files like .env, build artifacts, and generated files. It stages specific files and groups changes into at most two or three logical commits at the file level.
How is evidence handled in the PR description?
User-supplied artifacts are incorporated under Demo, Screenshots, or Evidence headings; if the user wants evidence but hasn't supplied it the skill asks; and non-observable changes skip evidence, with a validation note included for observable behavior.
All Files
3 filesSKILL.md8.6 KBViewreferences/pr-description-writing.md7.2 KBViewreferences/branch-creation.md1.8 KBViewAsking 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 viagh 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_rootfrom<repo-root>/.compound-engineering/config.yamlonly (<repo-root>=git rev-parse --show-toplevel). Do not read it fromconfig.local.yaml. Unset -><root>isdocs, 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 namingdocs_rootand the value -- never fall back todocs. - 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 readdocs.
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.
All Files
0 filesInstall ce-commit-push-pr
Download and extract the skill files to your .claude/skills/ directory.
Download ZIPClone the repository and copy the skill files to your project.
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
Copy





Home
