ce-commit-push-pr
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.
- 0
- Installs
- —
- Rating
- —
- Success rate
- 9
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 b656ac11d03abf18… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
Git Commit, Push, and PR
Asking the user: use the host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. Fall back to asking in chat only when no such tool is in the list or a real question call errors, 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 suppressed ask 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 handles 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 defines 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 uses the URL to pick the existing-PR path, 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 commit/push mechanics and default-branch handling via references/branch-creation.md. If stack mode committed its layers, skip to Step 4; Step 5 submits them.
Project publishing gate. Before publishing commits, resolve every applicable pre-push or review-ready requirement from the project's active instructions and conventions already in context and any additional scoped instructions governing the committed paths. Only evidence valid for the exact commit state being sent satisfies them; otherwise stop before the external write and report what is missing or failing. If none, proceed.
Never use git add -A or git add .. Name files in both add and commit so unrelated staged files stay out. Honor exclude:<paths>: leave and report them.
Step 4: Compose the PR title and body
You MUST read references/pr-description-writing.md in full — it defines the title and body content rules, including the rule to preserve an existing Related: / Fixes on rewrite. Then read references/compose.md for the three decisions to make before composing: the evidence decision; the teaching decision, where pr_teaching_section defaults on, pr_teaching_archive defaults off, and only an active (non-commented) key changes either; and the branding decision, 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 apply, preview, archival, and handoff. Before gh pr create, re-check PR presence: a matching PR takes the existing-PR path, exit-0 [] creates, non-zero blocks. Pass the body via --body-file <path>, never stdin — gh exits 0 with an empty body.
Completion is decided here. An interactive full workflow or pipeline stack submit is not done until ce-babysit-pr owns follow-on for the published PR. Reporting the PR URL alone is not success. Load the callee to choose the monitoring mode. If running it in this session, continue until its stop condition permits a final report.
Only babysit:off, CE config's auto_babysit: false, or a "Do not fire" case in references/apply-and-handoff.md skips it. 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.
Files
9- SKILL.md
deb35ce0327.7 KB - references/apply-and-handoff.md
f35d2392c310.4 KB - references/branch-creation.md
23536909fb1.8 KB - references/commit-and-push.md
b4b3857cdc2.4 KB - references/compose.md
7e3ad08f7f4.3 KB - references/context.md
4f3c2f652f5.7 KB - references/gh-stack-cli.md
e3f47f99673.8 KB - references/pr-description-writing.md
ee208826a123.1 KB - references/stack-submit.md
ffb1a9218711.6 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from EveryInc/compound-engineering-plugin8
Babysits an open GitHub PR until merge-ready. Use when asked to watch a PR over time — not for one-shot comment resolution or one CI failure. GitHub (incl. Enterprise) only.
Develop independent competing solutions to a defined brief, compare them, and synthesize a winning approach. Use when choosing well requires developing alternatives beyond their current form. Use ce-pov to judge developed material and ce-ideate to discover opportunities.
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.
Create a git commit with a clear, value-communicating message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate message.
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
Refresh the repo's captured learnings against the current codebase. Use when auditing stale, overlapping, superseded, or drifted learnings; avoid general refactor, debugging, or code review unless the learnings store is explicit.
Diagnosis loop for bugs and failing behavior. Use when asked to debug or fix failing or slow behavior.
Related methodology skillsscan passed
Break a tRPC backend into multiple services with custom routing links that split on the first path segment (op.path.split('.')) to route to different backend service URLs. Define a faux gateway router that merges service routers for the AppRouter type without running them in the same process. Share
Performs AI-powered code review on Git changes using the `ocr` CLI from alibaba/open-code-review. Use when the user asks to review code, review a pull request, review staged/unstaged changes, review a commit, or compare branches for code quality issues. Produces line-level review comments and can au
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Quality review of a change: is the logic right, is it safe, does it hold under real load, is risky code tested, is it fast enough, and is every line needed. Reads the connected code, not only the diff. Each finding is explained in plain English. Use for "review this", "code review", "review the last
F# testing patterns with xUnit, FsUnit, Unquote, FsCheck property-based testing, integration tests, and test organization best practices. Use when writing F# tests with xUnit, FsUnit, Unquote, or FsCheck.