pr

two modes: open (default) and review.

open mode

/skill:pr — open a PR for the current branch, resolve conflicts, watch CI.

•

identify branch and target

bash

git branch --show-current
git log --oneline main..HEAD

•

open the PR (or find existing one)

bash

gh pr create --fill --base main
gh pr view --json number,url,state  # if already exists

•

resolve merge conflicts if any:

bash

gh pr view --json mergeable,mergeStateStatus
git fetch origin main && git rebase origin/main
# resolve, git add, git rebase --continue
git push --force-with-lease

•
watch CI until complete:
bash
```
gh pr checks --watch --fail-fast
```
•
handle failures — read logs, fix, push, repeat:
bash
```
gh run view <run-id> --log-failed
```

output

write o/work/pr/pr.md with url, conflict status, check status, notes. write o/work/pr/update.md with 2-4 line summary.

review mode

/skill:pr <number> — review an incoming PR.

•

read metadata and linked issues

bash

gh pr view <number> --json title,body,headRefName,baseRefName,additions,deletions,files,comments,reviews
gh issue view <issue-number> --json title,body,labels  # for each linked issue

•
read the diff (for large diffs, prioritize non-test source files)
bash
```
gh pr diff <number>
```
•
read changed files in full for surrounding context.
•
analyze — check for: correctness, regressions, security, error handling, concurrency issues, style consistency.
•
check docs — are docs/changelog updated if behavior changed?
•
submit review only if user explicitly asks. default to --comment. never --approve or --request-changes without confirmation.
bash
```
gh pr review <number> --comment --body "<summary>"
```

output

code

## Review: PR #<number> — <title>

### Summary
<1-3 sentences>

### Good
- <things done well>

### Bad
- <issues to fix before merge>

### Ugly
- <concerns, not necessarily blockers>

### Verdict
<approve | request-changes | comment> — <1 sentence justification>

rules

•cite specific files and line numbers
•verify claims by reading code — do not guess
•do not nitpick style unless it harms readability
•if the diff is too large to fully review, state what was skipped