/pr

name: pr
description: >
  Open a GitHub pull request from the current branch, with a
  Conventional-Commits-style title and a body summarizing the commit
  range.
  TRIGGER when the user says "open a PR", "create a pull request",
  "push and PR", "submit this for review", "ship this PR", "open a
  draft PR", "file a PR for this branch", "/nyann:pr".
  Do NOT trigger on "merge the PR" / "approve the PR" / "review PR #N"
  — those are GitHub actions outside nyann's wedge. Do NOT trigger on
  "rebase" / "sync with main" / "update my branch" — that's the
  `sync` skill. Do NOT trigger when the user is on `main`
  or `master` (no PR to open); if detected, tell them to create a
  branch first and route to `new-branch`.

pr

Wraps `bin/pr.sh`. Two modes:

1. **Context-only** (`--context-only`). Collects branch + commit range

• suggested title without any network calls. The gh auth check is

skipped entirely in this mode (the script exits with the JSON summary before reaching the gh guard), so context-only also works when `gh` isn't installed or authenticated. Use this when the user wants you to synthesize a PR title and body from the commits before shipping. 2. **Create** (default). Pushes the current branch with `-u` tracking and invokes `gh pr create` with your title + body. Returns the PR URL.

0. Drift check (quick, non-blocking)

Run `bash bin/session-check.sh --flow=pr`. If it produces output, surface the line to the user verbatim. Do not block the flow.

1. Pre-flight

• Verify `gh` is installed and authenticated. `bin/pr.sh` does this

and emits `{skipped, reason}` with reason `gh-not-installed` or `gh-not-authenticated`. If you see a skip, relay it cleanly; don't try to install `gh` for the user.

• Verify the current branch is not `main`/`master`. If it is, refuse

and suggest `/nyann:branch` to create a feature branch first.

• Verify there are commits ahead of the base. If `ahead == 0`, tell

the user there's nothing to PR and suggest they commit first.

Pre-action guards

bash bin/pre-action-guard.sh --flow pr --target <cwd> [--profile <resolved-profile.json>]

| Exit | Meaning | Action | |---|---|---| | 0 | Pass (or advisory warnings) | Surface advisory `message` lines, continue | | 3 | Critical guard failed | Refuse to open the PR unless the user passes `--skip-guards`. Re-ask via AskUserQuestion. | | 4 | Confirm-severity guard failed | AskUserQuestion: "Proceed despite the warnings?" — explicit confirm required. |

Built-in PR guards include `branch-pushed` (advisory if upstream missing or ahead/behind) and `wip-commits` (advisory if the commit range still contains WIP/fixup commits). Profiles can promote either to `confirm` or `critical` via `guards.pr` in the profile.

`coverage-delta` is an **opt-in** guard — off by default. Note `guards.pr` REPLACES the built-in list (subset semantics — it does not append), so enable it by re-listing the built-ins alongside it: `"guards":{"pr":[{"name":"branch-pushed"},{"name":"wip-commits"},{"name":"coverage-delta"}]}`. Naming only `coverage-delta` would silently drop `branch-pushed` and `wip-commits`. It warns (advisory by default; promote to `confirm` via the profile) when the branch lowers test coverage versus the cached `.nyann/coverage-baseline.json`, tolerant up to `guards.coverage_delta_threshold` percentage points (default 0 = any drop warns). It reuses an existing CI coverage artifact (`coverage/coverage-summary.json`, `coverage.xml`, a Go coverprofile, a tarpaulin report) and **soft-skips** when none is present — it never runs the suite, so it's best paired with a profile/CI that already produces coverage. Refresh the baseline on the base branch / post-merge with `bash bin/guards/coverage-delta.sh --update-baseline`.

2. Decide base branch

`bin/pr.sh` resolves base in this order: `--base` arg > upstream tracking ref > `origin/HEAD` > `main`. Normally don't pass `--base`; trust the resolution. Override only when the user explicitly names a different target (e.g. "PR into develop").

3. Generate title + body

Run `bin/pr.sh --target <cwd> --context-only` first. Read the commit list from the JSON. Then synthesize:

• **Title**: single Conventional-Commits line. If the branch has one

commit, use that commit's subject verbatim. If many commits, pick the dominant type/scope and write a summary line. Keep it under ~70 chars for GitHub's UI.

• **Body**: GitHub-flavored markdown. Use this skeleton:

  ## Summary

  <2-4 bullets on what changed and why; derived from the commit list
  and any user intent they've shared>

  ## Test plan

  <bullets on what was verified; include lint / tests / manual checks
  the user has done in the session>

When the user has shared context in the session (e.g. "I verified X locally"), fold it into the Test plan. Don't invent tests that weren't run.

4. Confirm before shipping

Show the user the proposed title and body. Ask "Ship it?" before calling the create path. Exceptions: if the user's original phrasing was "just open the PR" / "ship it now" / "don't ask, just PR it", skip the confirmation.

5. Invoke create

bin/pr.sh \
  --target <cwd> \
  --title "<conventional-title>" \
  --body "<markdown-body>" \
  [--base <branch>] \
  [--draft]

`--draft` when the user says "draft PR" / "WIP PR" / "not ready for review yet". Relay the URL from `{url}` in the output back to the user.

6. Handling errors

• `gh pr create` can fail if a PR already exists for this branch. In

that case, suggest the user switch to `gh pr edit` or `/nyann:commit` to add more commits — don't retry the create.

• `git push` can fail if the remote is ahead. Surface the error

verbatim and suggest `/nyann:sync` or a manual pull+rebase.

When to hand off

• "now merge it" / "approve it" → out of scope; explain nyann doesn't

do merge/approve.

• "update my branch with main first" → `sync` skill.
• "write a commit message first" → `c