# Pr Shepherd

> Shepherd open PRs through a manual-merge workflow — assess risk, post consensus comments, propose merge order. Use when the user pastes a PR URL/number, says 'ok i merged X', 'whats next to merge', 'which of these are low risk'. Never merges.

- Skill: `dylanpulver/pr-shepherd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dylanpulver/pr-shepherd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dylanpulver/pr-shepherd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: dylanpulver (https://skillmd.com/u/dylanpulver)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dylanpulver/pr-shepherd

---


# pr-shepherd

The maintainer is the merge button by policy — the skill never merges. Everything around that button is this skill's job.
Replaces ~150 hand-typed shepherding prompts/month and the retyped merge doctrine.

## Doctrine (do not re-ask; do not drift)

- **Ignore CI status and review-required blocks.** The maintainer bypasses branch protection and merges manually. Judge **content risk only**: what the diff does, blast radius, rollback difficulty, data/schema danger. Never say "blocked on CI" or "needs approval".
- **GitHub Actions billing failures are noise.** Ignore them.
- **Never merge, close, or retarget without an explicit instruction naming the PR.** ("hold up i didnt say to actually merge anything" must never happen again.)
- **Check the repo's target-branch convention** in its CLAUDE.md/ledger before assessing (some repos target `staging` or `develop`, with `main` reserved for releases). Flag any PR targeting the wrong base as its own finding.

## Modes

**Assess (`<PR number(s)/URL>`):** for each PR — one-line what-it-does, content-risk (low/med/high + why), conflicts?, wrong base?, merge recommendation. Then post the consensus as a PR comment (this is standing policy: "for each pr once we come to a consensus, we should add a comment to the pr noting the consensus we came to and why"). End with recommended merge order.

**Next batch (`next batch`):** list open PRs (`gh pr list`), exclude ones the ledger shows already assessed-and-waiting, surface the lowest-risk merge candidates in order, with one-line ELI10 of what each gets us.

**Merged handback (`merged <n>` / "ok i merged X"):** update the ledger, check nothing depended on it (follow-up PRs to rebase?), answer "what's next" from the remaining queue — no re-derivation, no re-asking about doctrine.

## Ledger

`.claude/pr-ledger.md` in the repo — one line per PR: number, title, risk, consensus-comment link, status (open/assessed/merged/closed), date. Update it on every mode. This file is why "ok i merged 883, whats next" needs zero context.

<!-- example row -->
`883 | fix: retry payment-API token refresh on 401 | low | <consensus-comment link> | merged | 2026-07-14`

## After merges

Offer (don't auto-run) a channel update via the `slack-reply` skill (intent: update) covering the merged batch.