pr-manager

name	pr-manager
description	Workflow for handling PR follow-up nudges from the pr-manager plugin — addressing review comments, fixing CI failures, and keeping the PR dashboard accurate. Load this when a background event or message mentions pr-manager, a PR needing attention, unaddressed review comments, or failing CI checks.
metadata	{"emoji":"🔀","vellum":{"display-name":"PR Manager","category":"productivity","activation-hints":["a background event from source pr-manager arrived","asked to check on a pull request's review comments or CI status","asked to address PR feedback"],"avoid-when":["the user is asking to create a brand-new pull request"]}}

PR follow-up workflow

You received a nudge (or the user asked) to check on a pull request. The pr-manager plugin tracked this PR because this conversation created it. Work through the checklist below, then stop — do not invent extra work.

1. Get the ground truth

Never act on the nudge text alone — it is a snapshot. Re-fetch first:

gh pr view <number> --repo <owner/repo> --json state,mergeable,reviewDecision,statusCheckRollup,headRefName,headRefOid
gh pr checks <number> --repo <owner/repo>

For review threads (the nudge's comment excerpts are truncated):

gh api graphql -f query='query($owner:String!,$repo:String!,$number:Int!){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100){nodes{id isResolved comments(first:50){nodes{author{login} body path url}}}}}}}' -f owner=<owner> -f repo=<repo> -F number=<number>

If the PR is already merged or closed, say so briefly and stop.

2. Address review comments

For each unresolved thread from a human reviewer:

1. Decide: code change, or reply-only (question, disagreement, already fixed).
2. Make code changes on the PR's head branch. Pull first — check whether someone else pushed commits after yours (git log origin/<branch>). Never force-push over commits you did not write.
3. Reply in the thread so the reviewer sees acknowledgment (a real answer, not "Done."— say what changed):

   gh api repos/<owner>/<repo>/pulls/<number>/comments/<comment_id>/replies -f body='...'
   

4. Resolve the thread only when the concern is actually handled:

   gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -f id=<thread_id>
   

3. Fix failing CI

1. Read the failing check's logs: gh run view <run-id> --log-failed (find the run via gh pr checks).
2. Reproduce locally when practical; fix; push to the same branch.
3. If the failure is infrastructure flake (timeout, runner death), re-run it instead of changing code: gh run rerun <run-id> --failed.

If your tools are blocked

A nudge turn runs non-interactively; if bash/gh calls are denied because no interactive client is connected, do NOT retry the tool. Post ONE short message summarizing what needs attention (comment authors + gist, CI state) and tell the user two things: reply here to have you handle it, or add a trust rule for gh commands so future nudges can act autonomously. Then stop. The plugin never re-nudges the same comments, so you will not get another chance to spam.

4. Hard rules

• Merge conflicts: do NOT resolve them unless the user explicitly asks. Rebasing over a moved base branch is judgment work; a wrong auto-resolution is worse than a red "conflicts" badge. Mention the conflict in your reply and leave it.
• Do not merge the PR unless the user has asked you to.
• One pass per nudge: address what is actionable now, report, stop. Never loop waiting for CI to go green — the plugin will nudge again if needed.
• If nothing is actionable (comments already addressed, CI already green), do nothing and end quietly.

Manual tracking

If the user asks to put an existing PR on the dashboard and link it to this conversation:

bun run scripts/track.ts <pr-url>

(from this skill's directory; it records a candidate the next sync verifies). The dashboard app is called PR Manager — open it with skill_load("app-builder") then app_open("plugins~pr-manager~dashboard").