pr

name

pr

description

Create a pull request from the current branch for claude-statusline, into the right base for this repo's two-tier flow — feature branches (`dev-<feature>`) target `dev`, and `dev` itself targets `master` as a release PR. Analyzes the new commits, drafts a PR title and a Summary/Test-plan body matching this repo's existing PR style, previews it for approval, then creates it via the `gh` CLI. Use whenever the user says "pr", "pull request", "open a pr", "create pr", "ship it", "merge into dev", "merge into master", "raise a pr", or anything about getting the current branch merged — even if they don't say the word "skill".

/pr — Create Pull Request

Analyze the current branch's changes relative to its base branch, draft a PR title and body, preview for approval, and open the PR on GitHub.

Branch model

Work happens on feature branches named dev-<feature> (e.g. dev-notifications, dev-cjk-width), which PR into dev. dev is the integration branch; periodically a release PR merges dev into master. When creating a new feature branch, use the dev-<feature> name. This skill picks the base automatically from the current branch — no need to ask which one:

• On a feature branch (dev-<feature>, or any other branch that isn't dev/master) → base is dev.
• On dev → base is master (this is the release PR).
• On master → nothing to PR — stop.

Every command below that references "the base" means whichever of those was just selected. Substitute the literal branch name (dev or master) into every origin/<base> / --base <base> command.

Why this exists

Past PRs in this repo (before the dev branch existed) used a body of just ## Summary + ## Test plan — no separate "Changes" section, no conventional-commit-style title enforcement. This skill keeps that convention regardless of which base it's targeting. It also bakes in the two checks this project's CLAUDE.md calls out explicitly: cross-platform parity and a sensitive-content scan — this is a tool that runs on every user's machine, so a hardcoded personal path or leaked credential is a real risk, not a hypothetical one.

There's no CI configured in this repo and no automated test suite (CLAUDE.md: "No test framework. Manual testing required.") — so unlike a gate that runs pytest/tsc/eslint, this skill produces a manual test-plan checklist and doesn't run or wait on anything automated, unless .github/workflows shows up later (Step 7).

Step 1 — Pre-flight checks

Verify the GitHub CLI is available and authenticated:

gh --version && gh auth status

• If gh is not installed, tell the user to install it (winget install --id GitHub.cli on Windows, brew install gh on macOS/Linux) and stop.
• If gh is installed but not authenticated, tell the user to run gh auth login and stop.

Determine the base from the current branch (see Branch model above):

git branch --show-current

• Current branch is master → tell the user there's nothing to PR and stop.
• Current branch is dev → base = master.
• Anything else → base = dev.

Then gather branch state in one call (use origin/<base>, never a local branch, which can be stale):

git fetch origin <base> && git status --short && git log --oneline origin/<base>..HEAD && git diff --stat origin/<base>..HEAD

Handle these conditions before going further:

• No commits ahead? If origin/<base>..HEAD is empty, there's nothing to merge — tell the user and stop.
• Uncommitted changes? Warn that they won't be in the PR; suggest running the commit skill first to commit them.
• Existing PR for this branch?

  gh pr list --head "$(git branch --show-current)" --json number,title,url,state --jq '.[]'
  

  If an open PR exists, show its number/title/URL and ask via AskUserQuestion:
  • Update description — re-analyze and gh pr edit <number> --title "..." --body "..."
  • View it — print the URL and stop
  • Create new anyway — proceed (rare)
• Behind the base? Check:

  git log --oneline HEAD..origin/<base>
  

  If the base has moved on, ask via AskUserQuestion rather than syncing silently — finishing a sync may require a manual git commit (see the sync skill), which doesn't fit cleanly inside this flow:
  • Sync first (recommended) — stop here and invoke the sync skill, then re-run this skill once the branch is current
  • Proceed anyway — open the PR as-is; GitHub will flag any real conflicts on the PR page
• Not pushed / behind upstream? Note that git push will be needed in Step 6:

  git rev-list --left-right --count HEAD...@{upstream} 2>/dev/null || echo "no upstream yet"
  

Step 2 — Analyze the changes

git log --oneline origin/<base>..HEAD
git diff --stat origin/<base>..HEAD

Group changes by platform — macos/, linux/, windows/, plus assets/, README.md, CLAUDE.md for anything else. Watch for what this repo's CLAUDE.md calls out:

• Cross-platform parity: if the diff touches macos/ or linux/ without a matching windows/ change (or vice versa), note it in the preview — don't block, just flag, since a platform-specific fix can be intentional.
• exit added to install.*/uninstall.*: these scripts run via irm | iex on Windows and must never exit the user's shell session. Flag any new occurrence.
• Silent degradation: statusline.*, notify.*, git-refresh.*, subagent-statusline.* must always reach exit 0 and never write to stderr. Flag any new code path that could break this.

Sensitive-content scan (blocking). Inspect the diff:

git diff origin/<base>..HEAD | grep -nE "\.env|SECRET|PRIVATE KEY|BEGIN .*PRIVATE|password\s*=|api[_-]?key|token\s*="

• Secrets/credentials, private key blocks, hardcoded API keys or tokens.
• A hardcoded absolute personal path (/Users/<name>/..., C:\Users\<name>\...) instead of $HOME/~/$env:USERPROFILE — this tool runs on other people's machines, so that's a real bug, not just a leak risk.

If found, warn prominently and require explicit acknowledgment before creating the PR.

Step 3 — Draft the PR

Title — match this repo's actual style (gh pr list/git log history): a short, plain imperative sentence, no forced type(scope): prefix (e.g. "Add sound and visual toast notifications", "Fix 9 code review findings across all platforms"). Under 70 characters. For a dev → master release PR covering several feature merges, summarize the release as a whole rather than listing every commit title.

Body — this repo's merged PRs all use exactly this shape; match it rather than adding sections it doesn't use:

## Summary
- 2-4 bullets: the high-level what and why, calling out which platform(s) are affected

## Test plan
- [ ] Manual checks specific to what changed (see below)

Test plan guidance — pull items from CLAUDE.md's "What to verify after changes" list, scoped to the actual diff. Common ones:

• - [ ] Box renders without broken alignment or trailing characters
• - [ ] Colors display correctly (green/yellow/red thresholds)
• - [ ] No output to stderr
• - [ ] Exit 0 on empty, malformed, or missing JSON input
• - [ ] Git status row handles detached HEAD, no-repo, and fresh-clone states
• - [ ] Tested on <platform(s)> — note if the others were only verified by inspection
• - [ ] Installer re-run preserves existing config (if install/uninstall scripts changed)

Leave every box unchecked (- [ ]) — Claude hasn't run these manually, so it can't claim they passed. The user checks off what they've actually verified, either in the preview edit pass or after merging.

Step 4 — Verify before presenting

1. Title length — count characters, must be under 70.
2. File coverage — every changed file should be represented in the Summary or explicitly noted (binary, generated, lock file).
3. Re-scan for sensitive content — re-run the Step 2 grep; don't let a finding slip through.

Step 5 — Preview and confirm

Show the user:

• Branch: current-branch → <base>
• Commits: N
• Files changed: N
• Proposed PR: title (code block) and full body (fenced code block)

Then AskUserQuestion:

1. Create PR — push and create it exactly as shown (assigned to the user via @me)
2. Create as draft — same, but --draft
3. Edit — describe changes, re-preview

Do NOT create the PR until the user approves.

Step 6 — Create the PR

git push and gh pr create don't touch commit signing — pushing and opening a PR don't create new commits, so Claude runs these directly once approved.

1. Push if needed:

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

2. Create the PR against <base>, assigned to the user, using a heredoc so markdown survives:

   gh pr create --base <base> --assignee @me --title "the title" --body "$(cat <<'EOF'
   ## Summary
   - ...
   
   ## Test plan
   - [ ] ...
   EOF
   )"
   

   Add --draft if that was chosen. No Co-Authored-By / "Generated with Claude Code" footer — this repo's history doesn't use AI attribution (same convention as the commit skill).
3. Confirm and show the URL:

   gh pr view --json url,state,number,title --jq '{number,state,title,url}'
   

Step 7 — CI (only if configured)

Check the PR itself, not just the local checkout — a workflow added on the base branch after this branch diverged still runs against the PR, so ls .github/workflows alone can miss real checks:

sleep 8
gh pr checks <number>

If that reports no checks (and ls .github/workflows 2>/dev/null is also empty), report "No CI configured in this repo — nothing to wait on" and stop.

If checks exist, watch them instead of leaving the PR's status unknown:

gh pr checks <number> --watch --interval 20

Report pass/fail. On failure, run gh pr checks <number> and gh run view --job <id> --log-failed to surface the concrete error, then ask whether to fix now or leave the PR open red.

Edge cases

Situation	Action
gh not installed	Tell the user to install it, stop
gh not authenticated	Tell the user to run gh auth login, stop
On master	Nothing to PR — stop
On dev	Base is master — this is a release PR
Any other branch	Base is dev
No commits ahead of the base	Nothing to merge — stop
Branch already has an open PR	Offer: update description / view / create new
Uncommitted changes	Warn; suggest the commit skill first
Base ahead of branch	Ask: sync first (via sync skill) or proceed anyway
Sensitive content in diff	Block; list files; require explicit acknowledgment
Cross-platform parity gap	Flag in the preview, don't block — may be intentional
No .github/workflows	Report "no CI configured", stop after Step 6
No remote / upstream	git push -u origin <branch>; if no origin at all, ask for the URL first