pr-author

Reviewee-side PR drafting. The second of the GitHub reviewee triad; siblings are pre-push and pr-triage.

PR title and body get composed in-place each time with varying quality — title length, summary structure, test plan, base branch all improvised. This skill drafts them to a contract, shows you the draft, and hands you a ready-to-run command. It does not open the PR itself.

No Claude-initiated GitHub writes (triad-wide boundary — see pre-push). This skill drafts the PR and produces the exact gh pr create command for the user to run. Claude never executes gh pr create. Read-only gh / git calls (resolving base, listing commits) run freely.

Auto-fires via this description, not a hook (per skill-auto-fire).

When to run

Auto-fire when:

• About to run gh pr create (any form) — intercept and draft first.
• Just after a successful first push (git push -u origin <branch>) to a non-default branch that has no open PR (the pre-push handoff moment).
• The user says "open a PR", "create the pull request", "let's PR this", or equivalent.

Skip when:

• The user says "draft only, don't post" — still draft the title/body and surface it, but don't produce the run-it prompt; just hand over the text.
• The current branch is the default branch (nothing to PR from).

Manual trigger: /pr-author.

Procedure

1. Resolve PR context

All read-only:

• Branch — git rev-parse --abbrev-ref HEAD.
• Base branch — git symbolic-ref refs/remotes/origin/HEAD (strip refs/remotes/origin/); fall back to main → master → trunk by checking which exists on the remote.
• Fork case — gh repo view --json parent. If the repo has a parent (the user is contributing via a fork), the base is upstream's default branch, not origin's. Adjust and note it in the draft.
• Commits in range — git log <base>..HEAD --oneline.
• Diff stats — git diff --stat <base>..HEAD.
• Linked issues — scan commit messages in range for #NNN references.

2. Draft the PR

Title:

• One line, ≤70 chars (hard cap — gh truncates the title bar otherwise).
• Lowercase verb start (per git.md commit-format convention), no trailing period, no ticket prefix unless project convention requires it.
• Says what the change does for the reader, not how. "cut websocket frames by 70% with gzip", not "negotiate permessage-deflate on the websocket". Don't restate the branch name.

Body — per the contract below, layered on any existing template:

• Detect a PR template in order: .github/PULL_REQUEST_TEMPLATE.md → .github/pull_request_template.md → docs/PULL_REQUEST_TEMPLATE.md. If one exists, its content is the baseline; fill the skill's sections on top of it rather than replacing it. (Multiple templates under .github/PULL_REQUEST_TEMPLATE/ → v2; for v1, surface that they exist and let the user pick one to paste.)
• ## Summary — open with the problem in one or two plain sentences, in the user's words where they gave them (from the session, the issue, or the commit messages). Then 1–3 bullets on the fix. Not a list of every file or function touched; not a commit-log copy.
• ## Test plan — a checklist of how the change was verified or how a reviewer can verify it.
• Closes line — Closes #NNN when a commit referenced an issue and it's the issue this PR resolves. Only when confident; otherwise omit.
• No AI-attribution footer.

3. Surface the draft + hand over the command

Show the user:

• The drafted title and body (body in a copy-ready fenced block).
• The resolved base branch (and a note if it's a fork's upstream).
• The exact command they can run, body written to a temp file to avoid shell-escaping issues:

Ready to open. Run this yourself when you're happy with the draft:

```
gh pr create \
  --base <base> \
  --head <branch> \
  --title "<title>" \
  --body-file <path-to-tmp-body-file>
```

(Add `--draft` for a draft PR. I've written the body to <path> so quotes/markdown survive.)

Then ask: "Want me to revise the draft? (edit title / edit body / fork-base looks wrong / looks good)" — all options edit the draft, none of them post. "Looks good" ends the skill with the command in the user's hands.

The skill never runs gh pr create. It writes the body to a temp file and constructs the command; running it is the user's action. Even on an explicit "you run it", do not execute the gh write — restate the policy in one line ("I draft, you run — here's the command ready to paste") and hand the command over. The no-Claude-initiated-GitHub-writes boundary has no exceptions; a user who wants one-key submission can run the handed-over command directly.

What pr-author does NOT do

• Does not run gh pr create. Drafts and hands over the command. The user opens the PR.
• Does not post anything to GitHub. No comments, no labels, no reviewers assigned — title/body draft only.
• Does not auto-merge or set auto-merge. Out of scope; that's a GitHub setting and a user decision.
• Does not replace the PR template. Layers on top of an existing one; never discards it.
• Does not guess Closes #NNN. Only emits it when a commit clearly references the resolving issue.

Relationship to other organs

• pre-push — hands off to pr-author after a first push with no PR.
• pr-triage — the third triad skill; runs later, when review comments arrive on the opened PR — triages them into a checklist and routes the code actions (you write the replies).
• git.md — title format (lowercase verb start, no AI attribution).
• discover — optional, for project-specific PR conventions.