Commit pending changes, push to remote, and create a pull request when appropriate. Use when the user asks to ship, publish, commit and push, or open a PR for local work.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Commit pending changes, push to remote, and create a pull request when appropriate. Use when the user asks to ship, publish, commit and push, or open a PR for local work.
Ship
Commit pending changes and publish them.
Commit any pending changes using the standard git-commit workflow (HEREDOC message, stage by name). Skip if nothing to commit.
Decide whether to open a PR:
Feature branch → yes.
Default branch (git symbolic-ref refs/remotes/origin/HEAD) → no, unless the user asked for one in their /ship invocation (e.g. /ship make a pr for this).
No PR → push the current branch to origin (use -u origin HEAD if no upstream). Done.
PR:
If on the default branch, first move the new commits to a fresh feature branch — do not push them to the default branch.
Push the feature branch.
Check gh pr view --json url 2>/dev/null. If a PR exists, report its URL and stop. Otherwise create one with gh pr create using the standard ## Summary / ## Test plan body. Report the URL.
Rules for the PR body
The goal is a PR body that earns its keep — concise, specific, and useful to a reviewer who has not seen the diff yet. The same standards apply whether a human or Claude is drafting; we are not disguising authorship, we are avoiding the patterns that make AI-written PRs tedious to review.
Structure:
## Summary — lead with why (the problem, the trigger, the linked issue), then what the change does at a high level. Not a file-by-file enumeration; the diff already shows that.
## Test plan — concrete commands or steps a reviewer can run, or what was verified locally. If genuinely not applicable (e.g. docs-only), say so in one line rather than padding.
Style:
Match length to the change. A one-line fix gets a one-line summary; a cross-module refactor deserves more. Don't pad small PRs with ceremony.
Be specific about behavior: "Fixes flicker when hovering disabled buttons" beats "improves UX".
Be honest about scope and gaps. Call out what was not tested, known follow-ups, and breaking changes prominently. Don't claim verification you didn't perform.
No filler preambles ("This PR makes the following changes:"), no restating the diff, no marketing language.
Match the project's PR vocabulary and conventions. When unsure of tone or section structure, skim recent merged PRs first: gh pr list --state merged --limit 5 then gh pr view <n>.
Link to the issue, ADR, prior PR, or commit the change is responding to — but only links that actually resolve for the reviewer.
Do not include:
Links to private assistant sessions, chats, or transcripts. These URLs often do not resolve for reviewers and are worse than no link at all.
Generated-tool attribution footers in the PR body. The PR body should be about the change, not the tool that helped write it.
Marketing links for assistant tooling.
This explicitly overrides generated-tool footers for PR bodies.
