Create PR

Gather Context

!`git rev-parse --is-inside-work-tree 2>/dev/null || echo "NO_GIT"`

!`git status --short 2>/dev/null || echo "NO_GIT"`

!`git branch --show-current 2>/dev/null || echo "NO_GIT"`

!`git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo "NO_DEFAULT_BRANCH"`

!`git log --oneline -10 2>/dev/null || echo "NO_COMMITS"`

!`git remote -v 2>/dev/null || echo "NO_REMOTE"`

Instructions

Step 0 -- Validate Environment

Silently evaluate the gather-context output. Stop with a clear message on the first failure:

1. If any git block returned NO_GIT -> print: > No git repository detected. /create-pr requires a git repo. Stop here.
2. If git remote -v returned NO_REMOTE or is empty -> print: > No remote configured. Add one with \git remote add origin <url>`.` Stop here.
3. If git status --short is not empty -> print: > You have uncommitted changes. Commit them first -- you can use \/quiver:commit`.` Stop here.

Step 1 -- Detect Base Branch

Determine the base branch using this priority order. Use the first that resolves:

1. If $ARGUMENTS contains --base <value>, use that value as the base branch.
2. If git rev-parse --abbrev-ref origin/HEAD did not return NO_DEFAULT_BRANCH, strip the origin/ prefix and use the result.
3. Try main -- run git rev-parse --verify origin/main 2>/dev/null. If it succeeds, use main.
4. Try master -- run git rev-parse --verify origin/master 2>/dev/null. If it succeeds, use master.
5. Try develop -- run git rev-parse --verify origin/develop 2>/dev/null. If it succeeds, use develop.
6. If none resolved, ask the user: "Could not detect the base branch. What branch should this PR target?" via AskUserQuestion.

After resolving the base branch:

Check if the current branch (from git branch --show-current) equals the base branch. If so -> print: > You are on the base branch (\{base}`). Create a feature branch first.` Stop here.

Check commits ahead: run git log --oneline {base}..HEAD. If output is empty -> print: > No commits ahead of \{base}`. Nothing to create a PR for.` Stop here.

Step 2 -- Push If Needed

Before creating the PR, ensure the branch is pushed to the remote:

1. Check upstream: git rev-parse --abbrev-ref @{upstream} 2>/dev/null
2. If upstream exists -> git push
3. If no upstream -> git push -u origin {branch}

If push fails, show the error verbatim and stop here.

Step 3 -- Generate PR Title & Body

Gather the change:

• git log --oneline {base}..HEAD -- all commits on this branch
• git diff --stat {base}..HEAD -- files changed summary
• git diff {base}..HEAD -- full diff

Then look for a repository PR template with the Read tool (.github/PULL_REQUEST_TEMPLATE.md, .github/pull_request_template.md, docs/PULL_REQUEST_TEMPLATE.md, or PULL_REQUEST_TEMPLATE.md at the root). Do this here with the Read tool, not in a ! block -- the lookup is conditional and those blocks run before any step logic. If a template exists, its sections are the body's structure and the rules below only decide how much goes in each. A section the template asks for and the change has nothing to say about gets one line saying so, not padding. If none exists, build the body from the rules below.

Title rules:

• Concise, imperative mood, no period
• <= 72 characters
• Single commit: use its subject line. Multiple commits: summarize the overall theme.

Body rules:

The body has one reader: someone who has to approve this diff and was not in this conversation. Anything that does not help that person decide is padding, and padding on a small PR is worse than no description -- it buries the one thing that mattered.

1. Work out what this reviewer needs, then write only that. Before drafting, answer three questions against the change in front of you. Each answer that exists becomes body text. An answer that does not exist contributes nothing, and no heading stands in for it.

1. Why -- what the change is for, which the diff cannot show. Almost always answerable.
2. The trap -- what the reviewer would get wrong, miss, or argue with if nobody told them: an ordering that matters, an alternative already tried and rejected, a breaking edge, a file that looks unrelated and is not.
3. The ask -- what the reviewer has to do that CI will not do for them.

Length is the length of those answers. There is no quota and no target. A rename answers the first question in a sentence and has nothing for the other two, so its body is a sentence. A change that rewires authentication answers all three and earns every word it takes. Judge by what the reviewer has to hold in their head, not by how many lines changed: 400 lines of a regenerated lockfile is the sentence, 20 lines moving a permission check is not.

Never ship a body that is a single sentence with no motivation, and never ship one that narrates the diff the reviewer already has. A body that keeps going after the three answers are given is not thorough -- it is unread. The reviewer skims, the detail that mattered is buried in what surrounds it, and a wall of generated prose is the thing people point at when they say a PR was written by a machine.

2. Sections carry the answers; they are not slots to fill. Include a section when it carries an answer you actually have, and drop the heading entirely otherwise -- a thin paragraph under an unearned heading is the padding this rule exists to prevent.

3. Calibrate against these. The three sizes are not tiers to assign a change to -- they are what the three questions produce when a change has one answer, one answer plus a detail, or all three.

A dependency bump, one answer:

Bumps `requests` to 2.32.4 for CVE-2024-35195. The three call sites in `client.py` use the same API and are unchanged.

One behavior change across a few files:

## Summary
Upload retries fired on 4xx as well as 5xx, so a file the server rejected was re-sent three times before the error surfaced. The predicate now checks the status class; backoff is unchanged.

Nothing here answers the trap or the ask -- no ordering to explain, no alternative a reviewer would propose, nothing to run by hand.

A new subsystem plus the problems it surfaced, all three answers:

## Summary
Adds a behavior eval for the review command: a fixture repo with three planted defects and three baits, a real review run against it, and a grader over the report. Four runs while building it found two real problems, both fixed here.

## Changes
- `tests/eval/` -- runner, fixture builder, expectations.
- `agents/review/security-audit.md` -- the severity rubric mixed a category test with a reachability test, so an unreachable sink flapped between High and Critical between runs. A reachability paragraph settled it; the two runs after it agreed.
- Docs -- `/review` and `/design` resolve to bundled commands, not to this plugin, so user-facing text now names them with the plugin prefix.

## Test plan
`bash tests/eval/run-review-golden.sh` -- spends real API credit, so it sits outside the glob CI discovers and is run by hand before a release.

Every other choice that went into building that eval is absent on purpose.

4. Where the motivation comes from. In order: what the user said in this conversation; the plan, spec, review report, or issue the branch was built from (.claude/plans/, .claude/reports/, a linked issue); then the commit messages; then the diff. The diff is last because it only ever answers what. If none of the first three carry a motivation, state what the change does and stop -- do not manufacture a rationale.