| name | make-pr |
| description | Push the current branch and create or update a GitHub pull request with a good title, description, labels, and assignee. Use after the branch name is already conventional. |
/make-pr — Create or Update a Pull Request
Push the current branch and create (or update) a GitHub PR with title, description, labels, and assignee.
Workflow
0. Check branch
git branch --show-current
If on main (or master): run /make-branch skill first to move their changes to a feature branch. Do NOT proceed with PR creation from the main branch.
If on a placeholder / petname branch: run /make-branch to rename it before opening the PR. Petname branches are auto-generated names and should not become the public branch name of a PR. A branch is a placeholder if any of these match:
- Petname pattern:
^[a-z]+-[a-z]+$ (two lowercase words joined by a single hyphen, no slash, no digits — e.g. useful-pony, sound-midge, novel-aphid). Claude Code and similar tools auto-generate these.
- Generic placeholder name:
wip, tmp, temp, test, scratch, work, or similar.
A branch matching ^(feat|fix|refactor|docs|test|chore|perf|ci)/.+ is conventional — proceed with PR creation.
1. Gather context
Run these in parallel:
git log main..HEAD --oneline
git diff main...HEAD --stat
gh label list --limit 50 --json name,description
git config user.name
Also check if a PR already exists for this branch:
gh pr view --json number,url 2>/dev/null
2. Draft PR content
Title: <type>: <short description> (under 70 chars). Conventional types: feat, fix, refactor, docs, test, chore, perf, ci. Match the PR theme, not just the last commit.
Labels: pick from gh label list --json name,description output. Apply only labels scoped to PRs — read each description and skip issue-scoped ones (e.g. descriptions starting with "Issue ..."). Verdict labels like recommend-merge / recommend-close / recommend-triage are applied during review, not at creation. If no label clearly applies, add none.
Assignee: default to the git user (gh api user --jq '.login').
Body: read DESCRIPTION-QUALITY.md before writing. Pick the smallest structure that carries the signal. Do NOT mechanically apply a fixed template; calibrate to the scope of the change.
Body by scope
Small change (docs, single bugfix, dep bump, small refactor) — one motivation sentence, evidence if visual, one-item test plan. No ## Summary header — the lead IS the summary.
Follow-up to #144. The original example's inputs looked near-identical, so the
diff panels offered no contrast; this rewrite picks an edit-detection scenario
where each mode shows a distinct result.
## Test plan
- [x] `uv run python examples/diff.py --save` regenerates the asset
Medium change (new function, behavior change, multi-commit feature):
## Summary
- 3-5 bullets describing behavior and API surface, not implementation details
![evidence if visual]
## Test plan
- [x] tests added: `tests/...`
- [x] `make lint`
Large change (cross-cutting refactor, new subsystem) — add ## Why with real architectural motivation; link the issue or design doc that authorized the work.
Embedded images
Use a commit-SHA-pinned raw URL so the image survives branch deletion after merge:
https://github.com/<owner>/<repo>/raw/$(git rev-parse HEAD)/<path>
Branch-pinned URLs (raw/feature-branch/...) 404 once the branch is deleted, leaving the archived PR description broken.
Test plan calibration
Each item should describe a check that actually gated the change. Boilerplate dilutes meaningful items.
- Docs-only: one item, usually asset regen or render check. Don't pad with
make lint / pytest for changes that don't touch lintable / testable code.
- Bugfix: the new test that proves the fix + manual repro if applicable.
- Feature: tests added + lint + manual verification.
Anti-patterns to avoid
- Marketing words — "headline", "deliberately", "robust", "elegantly", "sells". Cut them.
- Before/after framing on small PRs — theater. The reviewer can compare against
main.
- Restating code comments in the body — descriptions are ephemeral; code comments persist. Don't duplicate.
## Why sections without a real why — if you can't add context the diff doesn't carry, skip the section.- Rigid templates over signal density — if a lean paragraph carries the meaning, don't wrap it in
## Summary ceremony.
3. Push and create/update
Draft vs ready — a draft PR is the native "not ready yet" signal, so the
maintainer's "needs my attention" filter is is:pr is:open draft:false (no
label needed). Pick the default from who is running this skill:
- User invoked it directly → open ready. They are vouching the branch is
finished; do not add a
--draft step they have to undo.
- Running autonomously / unsupervised (AFK,
/loop, an agent opening its own
PR) → open draft (gh pr create --draft). The work is unvetted; the user
flips it to ready (gh pr ready <number>) or merges after a look.
- An explicit "draft" / "ready" request in the prompt overrides this.
git push -u origin <branch> --force-with-lease
gh pr create --title "..." --body "..." --label "..." --assignee "..."
gh pr edit <number> --title "..." --body "..." --add-label "..." --add-assignee "..."
4. Return the PR URL
Always print the PR URL at the end so the user can click it.
Guidelines
- Always use
--force-with-lease (not --force) when pushing.
- Check if a PR already exists before creating — update it (
gh pr edit) instead of failing.
- For long PR bodies, write to a tempfile and pass via
--body-file to avoid shell quoting issues.
