option

Effectuer un commit, envoyer la modification et ouvrir une pull request. À utiliser lorsqu'on vous demande d'envoyer ou d'ouvrir une pull request, ou dans le cadre de processus portant uniquement sur la description de la pull request, comme la rédaction, la réécriture ou la description du corps d'une pull request.

...Développer tout
14
Heure mise à jour 26 août 2026

À propos ce-commit-push-pr

Effectue des commits, des pushes et ouvre une pull request avec une description adaptative, axée sur la valeur, dont la profondeur s'adapte à l'ampleur de la modification. Il est déclenché par des requêtes telles que « commit et PR », « publier ceci », « créer un PR » ou « ouvrir une pull request », et gère également les flux portant uniquement sur la description, tels que « rédiger une description de PR » ou « réécrire le corps d’une PR », sans commit ni push. Il définit trois modes : description uniquement (exécuter uniquement l'étape de description et afficher le résultat), mise à jour de la description (actualiser le corps d'une pull request ouverte existante et l'appliquer via `gh pr edit`), et le workflow complet (exécuter toutes les étapes dans l'ordre). Lorsqu’il doit poser une question à l’utilisateur, il utilise l’outil de question bloquante de la plateforme, avec une solution de secours via le chat.

Le workflow recueille le contexte Git — statut, diff de l’arborescence de travail, branche actuelle, commits récents, branche distante par défaut et toute pull request existante — à l’aide de sections préremplies dans Claude Code ou d’une commande de repli de contexte fournie ailleurs. L’étape 1 détermine l’état de la branche et de la pull request, puis oriente le processus en fonction de la situation : un HEAD détaché invite à créer une branche de fonctionnalité ; le fait d’être sur la branche par défaut avec du travail en cours crée automatiquement une branche de fonctionnalité (car le push direct de la branche par défaut n’est pas pris en charge) ; le fait d’être sur la branche par défaut sans travail en cours interrompt le processus, tandis qu’une branche de fonctionnalité se poursuit. L’étape 2 détermine les conventions, en s’alignant sur le style du dépôt et en privilégiant par défaut les commits conventionnels ; en cas d’ambiguïté, elle privilégie « fix: » plutôt que « feat: » et réserve « feat: » aux fonctionnalités véritablement nouvelles.

L’étape 3 consiste à valider et à pousser : elle consulte un guide de création de branches lorsqu’elle se trouve sur la branche par défaut, regroupe les fichiers modifiés en deux ou trois commits logiques au maximum au niveau des fichiers (en évitant `git add -p`, `git add -A` ou `git add .`, qui peuvent inclure par inadvertance le fichier `.env` et les artefacts de compilation), puis effectue le push avec `git push -u origin HEAD`. Étape 4 : rédaction du titre et du corps en lisant intégralement un guide obligatoire sur la rédaction de la description d’une pull request et en prenant une décision concernant les preuves — en intégrant les artefacts fournis par l’utilisateur sous les rubriques « Démonstration », Captures d’écran ou Preuves, en demandant à l’utilisateur de fournir des preuves s’il le souhaite mais ne les a pas encore fournies, et en omettant les preuves pour les modifications non observables – tout en incluant une note de validation concise pour les comportements observables. L’étape 5 applique et génère un rapport, en créant une nouvelle PR avec `gh pr create` ou en mettant à jour une PR existante avec `gh pr edit`, en prévisualisant le titre et le corps avant d’appliquer une mise à jour, et en écrivant le corps dans un fichier temporaire.

FAQ

Quels modes cette compétence prend-elle en charge ?

Trois : « description uniquement » (rédaction et affichage de la description d’une PR), « mise à jour de la description » (réécriture du corps d’une PR ouverte existante et application de celle-ci), et le workflow complet qui effectue un commit, un push, puis ouvre ou met à jour une PR.

Que se passe-t-il si je l’exécute alors que je me trouve sur la branche par défaut ?

S’il y a du travail à effectuer, elle crée automatiquement une branche de fonctionnalité, car le push direct de la branche par défaut n’est pas pris en charge. S’il n’y a pas de travail, elle le signale et s’arrête.

Comment fait-il la distinction entre « fix: » et « feat: » pour les commits conventionnels ?

Il s’adapte au style du dépôt et utilise par défaut les commits conventionnels, en privilégiant « fix: » plutôt que « feat: » en cas d’ambiguïté, car l’ajout de code visant à corriger un comportement défectueux ou manquant est considéré comme une correction. « feat: » est réservé aux fonctionnalités véritablement nouvelles.

Pourquoi évite-t-il les commandes `git add -A` et `git add .` ?

Parce que ces commandes incluent des fichiers tels que .env, des artefacts de compilation et des fichiers générés. Il prépare des fichiers spécifiques et regroupe les modifications en deux ou trois commits logiques au maximum au niveau des fichiers.

Comment les preuves sont-elles gérées dans la description de la PR ?

Les éléments fournis par l'utilisateur sont intégrés sous les rubriques « Démo », « Captures d’écran » ou « Preuves » ; si l'utilisateur souhaite fournir des preuves mais ne l'a pas fait, la compétence le lui demande ; et les modifications non observables ne nécessitent pas de preuves, une note de validation étant incluse pour les comportements observables.

Tous les fichiers

3fichiersSKILL.md8,6KoAfficherreferences/pr-description-writing.md7,2KoAfficherreferences/branch-creation.md1,8 KoAfficher
Voir sur 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.

Tous les fichiers

0 fichiers

Installer ce-commit-push-pr

Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.

Télécharger le ZIP

Clonez le dépôt et copiez les fichiers de compétence dans votre projet.

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

Copier Copier
Configuration rapide: Copiez le dossier de la compétence dans .claude/skills/ ; Claude la détectera automatiquement et l'utilisera.

Compétences similaires

github-project-management
Heure mise à jour 29 juin 2026
using-git-worktrees
Heure mise à jour 29 juin 2026
readme-blueprint-generator
Heure mise à jour 5 juillet 2026
finishing-a-development-branch
Heure mise à jour 29 juin 2026
OR