pr

name	pr
user-invocable	false
description	Open the pull request for the current issue, following specwright PR conventions — resolves branch/base, pushes if needed, fills the repo PR template, English Conventional-Commit title and body, records the runtime-verification results, no AI attribution. Use as the delivery step of the issue pipeline, or whenever the user asks to open a PR.

pr — Open the issue's pull request

The single sanctioned way to open a PR in a specwright repo — PR via this command. Never open a PR any other way.

Announce at start: "Opening the pull request..."

Inputs

$ARGUMENTS (optional): target base branch and/or extra instructions — e.g. "to main", "label bug", "draft". Empty → base defaults to main.

Safety gate — never from main

Check the current branch first:

git branch --show-current

If it is main or master, stop and tell the user to create a feature branch first. Do not proceed.

Resolve consent — find the issue

Find the issue driving this branch: the spec.md whose branch: matches the current branch, searched under .specwright/issues/*/ and .specwright/milestones/*/issues/*/ (else the most recently modified issue folder in either tree).

• Issue found → the issue's approved design is the standing consent: open the PR now without asking.
• No matching issue (ad-hoc PR) → proceed only if the user explicitly invoked this skill.

Push the branch if needed

git ls-remote --heads origin "$(git branch --show-current)"

If the branch is not on origin, push it (covered by the standing consent — never push main/master):

git push -u origin "$(git branch --show-current)"

Resolve the PR template

Use the repo's template as the body skeleton:

cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || cat .github/pull_request_template.md 2>/dev/null

If present, fill its sections (do not drop required checklist items — answer them honestly; for a maintainer dogfood PR that edits .specwright/, annotate rather than silently tick). If absent, print one line — PR template not found; using embedded fallback — and use the Embedded fallback at the bottom of this file.

Title and body

• Title — English, Conventional Commits: <type>(<scope>): <concise summary>. Types: feat, fix, docs, refactor, chore, test, ci. Derive the scope from the area the diff touches.
• Body — English (committed artifacts are English). Top: ONE product-level sentence (no filenames, no pipeline mechanics) describing WHAT the PR does, then 2–5 concrete bullets (resource + action). For an issue-driven PR, fill ## Summary with context/decisions and link the issue artifacts as absolute GitHub URLs on the branch: issue.md, spec.md, tasks.md. Exception — local commit mode (git check-ignore -q .specwright/milestones succeeds): those files are git-ignored and never pushed, so a GitHub URL would 404 — omit the links and inline one line instead: the artifacts live only in the local (un-pushed) .specwright/ vault. Record in the template's test-plan/quality section: the quality-gate results (what ran, what passed) and the runtime-verification record — each AC-N with how it was verified by observed behavior, or needs-human-verification + reason. For an issue-driven PR, the same section also names the three plan self-review gates (mechanical validator, spec-document-reviewer, review-spec) and their outcomes.
• No AI attribution anywhere — no "Co-Authored-By: Claude", "Generated by …".

Degradation — ordered pre-flight

Run these checks in this order, before gh pr create. gh pr create is never invoked as a probe, and never with a placeholder title or body — it runs once, with the real, fully-filled title and body from the previous step.

1. Remote — inspect git remote -v first. Empty, or no GitHub remote → stop before anything else: explain; do not fabricate a PR.
2. gh — no gh on PATH, or gh auth status fails → stop: print the exact git push + manual PR-creation steps for the user to finish.
3. Only when both pass, run gh pr create (next section).

Durable record on either stop branch: write the fully-filled PR body — template or embedded fallback, including the quality-gate results and the per-criterion runtime-verification record — to <issue-folder>/pr.md, and say in the stop explanation that the record was written there. The delivery record must survive the session.

Create the PR

gh pr create --base <BASE> --title "<TITLE>" --body "<BODY>" --assignee @me

Keep --assignee @me unless $ARGUMENTS says otherwise. Add --draft only if asked. After creation, print the PR URL.

Stacked base (milestone issues)

When the issue's board dependency is not yet merged, the branch was cut from the dependency's branch — pass that branch as --base and say so in the body ("stacked on #"). Re-target to main after the dependency merges.

Embedded fallback (when the repo has no PR template)

In local mode, replace the ## Issue block's GitHub URLs with a single line: the artifacts live in the local (un-pushed) .specwright/ vault.

<one product-level sentence — what this PR does>
- <concrete change 1>
- <concrete change 2>

## Summary
<context, motivation, key decisions, non-goals, trade-offs>

## Issue
- issue: <github-url>
- spec: <github-url>
- tasks: <github-url>

## Quality gate
<tests/validators run, manual checks, CI output>

## Runtime verification
<AC-N: verified how — or needs-human-verification + reason>