/yas-pr

name: yas-pr
description: Assemble a pull request that follows this repo's PR template, then open it as a draft. Use when the user wants to open, create, submit, or raise a PR for the current branch.

YAS PR

Fill in this repo's PR template from the current branch, then open a draft PR. Do not invent the template structure — read it from the repo so the two never drift.

Steps

1. **Sanity-check the branch and hooks.** Confirm the current branch is not `main` and has commits ahead of `origin/main`. If it's `main` or has no diff, stop and tell the user. Also check `git config --local --get core.hooksPath`; if it isn't `.github/hooks`, offer to run `make hooks` so the contributor gets pre-commit checks (don't enable it without their yes).

2. **Read the template.** Load `.github/pull_request_template.md`. This is the single source of truth for the section structure — mirror its headings exactly.

3. **Draft Context and Changes.** From `git diff main...HEAD` plus the conversation:

• **Context** — *why* the change is needed; the higher-level goal/problem. Link the related

issue/PRD (`.scratch/<feature>/...`) if one exists. If this PR bumps the version (step 8), reference the new version number here.

• **Changes** — *what* changed and *how* it works. Group related changes and give each group

its own `###` (H3) heading. Under each heading, break the distinct points out into bullet points rather than one long run-on sentence — a wall of text is hard to read. Present these as a draft for the user to edit; don't fabricate motivation you can't infer.

4. **Embed system info.** Run `make pr-info` and paste its output into the System info fenced block verbatim.

5. **Run tests.** Run `uv run pytest`. If green, tick the tests checkbox. If red, show the failures and ask the user whether to fix first or proceed. Optionally also run `uv run ruff check` and `uv run mypy .` and note results.

6. **Benchmark.** Run `make bench` (times this branch vs `main` via a throwaway git worktree). If `hyperfine` is not on PATH, `bench.py` prints an install hint and falls back to a Python timer — before letting it fall back, offer to install hyperfine (`apt`/`brew`/`cargo`) and ask the user; only fall back if they decline. Paste the paste-ready table into the Benchmark block. Tick "N/A — no performance-relevant change" instead only for docs/config-only PRs.

7. **Before/after screenshots.** For any visible rendering/layout/glyph change, fill the **Screenshots / recording** section by **delegating to the `pr-screenshotter` agent** (see its own file for what it does). Drop the table it returns **verbatim** into the Screenshots / recording section.

• Don't render or push images yourself — that's the agent's whole job; you just place the

table it returns.

• If the change isn't visible (logic/docs/config-only), skip this and tick the section's

"N/A — no visible change" escape honestly.

• The agent commits + pushes to the screenshots repo's `main`; flag that to the user when you

present the body, since it's an outward-facing side effect of this PR flow.

8. **Bump the version (only if the statusline's behaviour changed).** If the diff changes the statusline tool or its behaviour — anything a user would notice (rendering, layout, glyphs, config knobs, new stats, output format) — bump the version before creating the PR. Work out the next version from the current one (`uv version --short`) per semver, then run `VERSION=0.X.Y make version/bump`. This is an outward-facing action — it commits **and pushes** the bump (`plugin.json`, `pyproject.toml`, `uv.lock`) — so confirm the new number with the user before running it. Then reference the new version in the Context section.

• Skip the bump for developer-only changes that users never see: tests, the Makefile, hooks,

CI, dev deps, docs, OpenSpec specs, etc. When in doubt about whether a change is user-facing, ask rather than bumping blindly.

9. **Confirm, then create the draft.** Show the fully assembled body (Screenshots section already populated with the agent's table). After the user confirms, run `gh pr create --draft` with that body. Print the PR URL and tell the user to click "Ready for review" when done.

Notes

• Keep checkbox N/A escapes honest — only tick "N/A — no behaviour change" / "N/A — no visible

change" when that's actually true.

• `gh pr create --draft` is an outward-facing action: never run it before the user confirms the

body.