Option

Committen, pushen und einen PR eröffnen. Verwenden Sie diese Funktion, wenn Sie aufgefordert werden, einen PR zu veröffentlichen oder zu eröffnen, oder für Abläufe, die ausschließlich die Beschreibung eines PR betreffen, wie das Verfassen, Überarbeiten oder Beschreiben des PR-Textes.

...Alle erweitern
14
Zeit aktualisiert 26. August 2026

Über ce-commit-push-pr

Führt Commits und Pushes durch und eröffnet einen Pull Request mit einer anpassungsfähigen, wertorientierten Beschreibung, deren Ausführlichkeit sich nach dem Umfang der Änderung richtet. Es wird durch Anweisungen wie „Commit und PR“, „Veröffentlichen“, „PR erstellen“ oder „Pull-Request öffnen“ ausgelöst und verarbeitet auch reine Beschreibungsabläufe wie „PR-Beschreibung verfassen“ oder „PR-Text überarbeiten“, ohne dabei zu committen oder zu pushen. Es definiert drei Modi: „Nur Beschreibung“ (nur den Beschreibungsschritt ausführen und das Ergebnis anzeigen), „Beschreibung aktualisieren“ (den Text eines bereits offenen Pull-Requests aktualisieren und über „gh pr edit“ anwenden) und den vollständigen Workflow (alle Schritte der Reihe nach ausführen). Wenn der Benutzer um eine Eingabe gebeten werden muss, wird das blockierende Frage-Tool der Plattform mit einem Chat-Fallback verwendet.

Der Workflow erfasst den Git-Kontext – Status, Diff des Arbeitsbaums, aktueller Branch, letzte Commits, den Remote-Standard-Branch sowie alle vorhandenen PRs – mithilfe vorab ausgefüllter Abschnitte in Claude Code oder eines anderweitig bereitgestellten Kontext-Fallback-Befehls. Schritt 1 ermittelt den Zweig- und PR-Status und leitet je nach Situation weiter: Bei einem „detached HEAD“ wird zur Erstellung eines Feature-Zweigs aufgefordert; befindet man sich auf dem Standardzweig und hat Arbeit vor sich, wird automatisch ein Feature-Zweig erstellt (da das direkte Pushen des Standardzweigs nicht unterstützt wird); befindet man sich auf dem Standardzweig ohne Arbeit, wird der Vorgang angehalten, und bei einem Feature-Zweig wird fortgefahren. Schritt 2 legt Konventionen fest, passt sich dem Repo-Stil an und verwendet standardmäßig konventionelle Commits, wobei bei Mehrdeutigkeit „fix:“ gegenüber „feat:“ bevorzugt wird und „feat:“ für wirklich neue Funktionen reserviert bleibt.

Schritt 3 führt Commits und Pushes durch: Es konsultiert eine Referenz zur Zweigerzeugung, wenn es sich auf dem Standardzweig befindet, gruppiert geänderte Dateien auf Dateiebene zu höchstens zwei oder drei logischen Commits (wobei „git add -p“ und „git add -A“ oder „git add .“ vermieden werden, da diese „.env“-Dateien und Build-Artefakte mit einbeziehen könnten) und führt den Push mit „git push -u origin HEAD“ durch. Schritt 4: Verfassen von Titel und Text durch vollständiges Lesen einer erforderlichen Anleitung zum Verfassen von PR-Beschreibungen und Treffen einer Entscheidung bezüglich der Nachweise – dabei werden vom Benutzer bereitgestellte Artefakte unter den Überschriften „Demo“, „Screenshots“ oder „Nachweis“ ein, fragt nach, wenn der Benutzer Nachweise wünscht, diese aber nicht bereitgestellt hat, und überspringt Nachweise für nicht beobachtbare Änderungen – wobei ein prägnanter Validierungshinweis für beobachtbares Verhalten eingefügt wird. Schritt 5 führt die Anwendung und Meldung durch, erstellt einen neuen PR mit `gh pr create` oder aktualisiert einen bestehenden mit `gh pr edit`, zeigt eine Vorschau des Titels und des Textkörpers an, bevor eine Aktualisierung angewendet wird, und schreibt den Textkörper in eine temporäre Datei.

FAQ

Welche Modi unterstützt dieses Skill?

Drei: „Nur Beschreibung“ (lediglich eine PR-Beschreibung verfassen und ausgeben), „Beschreibung aktualisieren“ (den Text eines bestehenden offenen PR neu verfassen und anwenden) sowie den vollständigen Workflow, der Commits durchführt, pusht und einen PR eröffnet oder aktualisiert.

Was passiert, wenn ich das Skript auf dem Standard-Branch ausführe?

Wenn Arbeit ansteht, wird automatisch ein Feature-Branch erstellt, da das direkte Pushen des Standard-Branches nicht unterstützt wird. Wenn keine Arbeit ansteht, wird dies gemeldet und der Vorgang beendet.

Wie entscheidet das Tool bei konventionellen Commits zwischen „fix:“ und „feat:“?

Es passt sich dem Repo-Stil an und verwendet standardmäßig konventionelle Commits, wobei bei Unklarheiten „fix:“ gegenüber „feat:“ bevorzugt wird, da das Hinzufügen von Code zur Behebung fehlerhafter oder fehlender Funktionen eine Korrektur darstellt. „feat:“ ist für wirklich neue Funktionen reserviert.

Warum vermeidet es „git add -A“ und „git add .“?

Weil diese Befehle Dateien wie .env, Build-Artefakte und generierte Dateien mit einbeziehen. Es stellt bestimmte Dateien bereit und gruppiert Änderungen auf Dateiebene in höchstens zwei oder drei logische Commits.

Wie werden Belege in der PR-Beschreibung behandelt?

Vom Benutzer bereitgestellte Artefakte werden unter den Überschriften „Demo“, „Screenshots“ oder „Nachweise“ eingefügt; wenn der Benutzer Nachweise wünscht, diese aber nicht bereitgestellt hat, fragt die Funktion nach; bei nicht beobachtbaren Änderungen werden Nachweise übersprungen, wobei ein Validierungshinweis für beobachtbares Verhalten hinzugefügt wird.

Alle Dateien

3DateienSKILL.md8,6KBAnzeigenreferences/pr-description-writing.md7,2KBAnzeigenreferences/branch-creation.md1,8 KBAnzeigen
Auf GitHub ansehen

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.

Alle Dateien

0 Dateien

ce-commit-push-pr installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

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

Kopieren Kopieren
Schnelle Einrichtung: Kopiere den Skill-Ordner nach .claude/skills/. Claude erkennt den Skill automatisch und nutzt ihn.

Ähnliche Skills

github-project-management
Zeit aktualisiert 29. Juni 2026
using-git-worktrees
Zeit aktualisiert 29. Juni 2026
readme-blueprint-generator
Zeit aktualisiert 5. Juli 2026
finishing-a-development-branch
Zeit aktualisiert 29. Juni 2026
OR