Shepherd pull requests from open to merge-ready

The skill carries a GitHub PR or GitLab MR from "just opened" to "nothing left unanswered" across bot review rounds, without a human refreshing the page. Three rules govern the loop: verify every finding against the actual code before believing a bot's severity badge (bots are often right and confidently wrong often enough to matter); give every thread a reply and a resolution, since silence reads as ignored; and never post a "fixed" reply or resolve a thread until the fix is pushed to the remote branch (rejections need no push).

Each round is harvested with the bundled script, quoted verbatim from the source:

"<skill-dir>/scripts/threads.sh" <N> > /tmp/pr-<N>-round-<k>.json

This returns both inline review threads (which carry a thread_id to resolve and reply_to to reply inside) and top-level review bodies (answered with one PR comment, no thread to resolve) - reading only one surface silently misses half the findings. Before filtering, the raw totals must be checked against the schema, since a misspelled jq field fails silently empty. A reviewer only counts as having seen the current push if its review carries a commit_id (GitHub) or debate_head (debate-review) matching the head SHA; other GitLab reviewers carry no such field, so coverage must be reported as "unknown" rather than assumed. Two author types count as reviewers: bots flagged author_bot: true, and any thread whose first comment carries a <!-- debate-review:... --> marker (posted from the PR author's own account but still a reviewer thread). Anything else from a human is out of scope for autonomous fixing and gets surfaced to the user.

Findings are classified by actual consequence, not by bot-assigned severity: blocking covers real bugs, security/authorization/data-integrity exposure, contract or spec violations, migration hazards, and failing or newly-flaky checks; everything else (naming, docs, style, micro-perf) is non-blocking. Ambiguous findings are held as blocking until read enough to demote - an over-cautious fix costs minutes, a missed P1 costs a production bug. Blockers are fixed autonomously without asking: reproduce with a failing-then-passing test where practical, run the repo's own gate (and any installed guard skill) before pushing, and push once per round rather than once per finding. Each closed thread gets a reply opening with "I am <model-slug> writing on behalf of <user>" naming the fix commit (confirmed), the counter-evidence (rejected, no push needed), or the filed issue link (deferred), then resolves. Non-blocking findings are batched into one per-round message with a fix-now/issue/reject recommendation each, and ride the next consolidated push rather than a dedicated one.

One invocation covers the initial harvest plus at most two repair pushes and two re-review cycles unless told to continue. debate-review is a local script (node "<skill-dir>/scripts/review-pr.mjs" <pr-url>, 10-20 minutes, one head sha per run); Codex is a GitHub app mentioned via @codex review (8-15 minutes); Greptile re-reviews every push on its own. The merge gate requires an explicit clean round from the repo's primary reviewer on the exact final head SHA - Codex saying "no findings" against that head, or debate-review's debate_agreed/debate_contested both zero with no unresolved threads - and the PR is re-harvested for late comments before ever proposing a merge, which the user, never the skill, decides.

Use it when a PR/MR has accumulated bot review threads needing verification, fixes, replies, and resolution, or when driving a PR through multiple review rounds to a mergeable state. Speak up instead of grinding through: scope-creeping findings, contradicting bots that code and tests can't settle, a finding recurring after a retry, any human reviewer comment, CI failing for infrastructure reasons, or an exhausted repair budget.

Input is a PR/MR number or URL on GitHub or GitLab. Output is a sequence of pushed fixes with named commits, every review thread replied to and resolved, filed issues for deferred non-blockers, and a final report of rounds run, blockers fixed, rejections with reasons, and CI state - handed to the user for the actual merge decision.

Developers or agents who want a PR driven through repeated bot-review rounds to a clean, mergeable state without manually re-reading each round's findings and re-triggering reviewers by hand.