shepherd

---
name: shepherd
description: "Use when asked to shepherd, babysit, monitor, or poll open pull requests or merge requests — including triaging review comments, detecting CI failures, fixing trivial CI issues, and keeping PRs/MRs moving without manual intervention."
---

# Shepherd

## Core principle

Poll open PRs (GitHub) and MRs (GitLab) in a loop, fix all outstanding issues locally first, then push fixes, then resolve review threads, then wait for CI. Never sit idle when a PR has unaddressed feedback or a failing CI check.

## Platform detection

Use `git remote get-url origin` to determine the platform:

| Remote URL pattern | Platform | CLI tool | ID prefix |
|---|---|---|---|
| `github.com` | GitHub | `gh` | `#` |
| `gitlab.*` | GitLab | `glab` | `!` |

Use the detected CLI tool (`gh` or `glab`) for all commands below. The skill uses `PR` generically for both pull requests and merge requests.

## Command reference

| Operation | GitHub (`gh`) | GitLab (`glab`) |
|---|---|---|
| List open PRs | `gh pr list --state open --json number,title,headRepository,baseRefName,statusCheckRollup` | `glab mr list --source-branch $(git branch --show-current) --output json` |
| View PR details | `gh pr view <#> --comments --json comments` | `glab mr view <!> --comments` |
| Check CI status | `gh pr checks <#>` | `glab mr view <!>` (check `pipeline` or `head_pipeline` fields) |
| View CI logs | `gh run view <run-id> --log-failed` | `glab ci trace <job-id>` |
| List CI pipelines | — | `glab ci list --mr <!>` |
| Add comment | `gh pr comment <#> --body "..."` | `glab mr note <!> --message "..."` |
| Merge | `gh pr merge <#> --squash --delete-branch` | `glab mr merge <!> --squash` |
| Approve | `gh pr review <#> --approve` | `glab mr approve <!>` |

## When to use

- User says "shepherd my PRs", "babysit my PRs", "watch my PRs", "monitor open PRs", or "poll PRs" — applies to GitHub PRs and GitLab MRs interchangeably
- User has open PRs that need ongoing attention across minutes or hours
- You're asked to handle PR review feedback autonomously
- CI keeps failing on issues you can fix (lint, format, minor test breakage)

**Do NOT use when:**
- The failure requires domain knowledge you don't have (ambiguous test failure, architectural feedback)
- The user explicitly says to do something else first
- There are no open PRs to shepherd

## Core loop

```
Detect platform: git remote get-url origin
While the user wants monitoring:
  1. List open PRs (see command reference)
  2. For each PR:
     a. Check for new comments
     b. Triage comments (see Comment Triage below)
     c. Fix ALL actionable issues locally — do not push yet
     d. If any changes made, push once with [autofix] prefix in the message
     e. Check CI status (see CI Fix Workflow below)
     f. If CI failing, follow CI Fix Workflow
     g. If changes pushed and CI green, comment "ready for re-review" if requested
  3. Wait an appropriate interval before polling again
```

## Polling interval

- **30-60 seconds** when actively fixing issues
- **2-5 minutes** when all PRs are waiting on review / CI is running
- **10+ minutes** when PRs have no new activity for several cycles

Track which comments you've already seen to avoid re-processing. Compare against your last poll's comment set (timestamps/IDs).

## Comment triage

| Comment type | Signal | Action |
|---|---|---|
| Approval / LGTM | "LGTM", "ship it", `APPROVED` review / GitLab approval | Check CI is green, then offer to merge or merge if instructed |
| Change request | "please change", "request changes", `REQUEST_CHANGES` | Read the specific feedback, fix locally |
| Nit / suggestion | "nit", "optional", "consider" | Apply if trivial (rename, formatting). Skip if debatable — ask user |
| Question | "why", "what about", "did you consider" | Answer the question. If unsure, relay to user |
| CI reminder | "tests failing", "CI is red", "pipeline failed" | Note the failure, then follow CI Fix Workflow after pushing |
| Merge conflict | "needs rebase", "conflicts" | Rebase on base branch, push. If conflicts are complex, report to user |

**Comment resolution rules:**
- Fix ALL actionable issues on a PR before pushing any changes
- Do NOT push after each comment — batch all fixes into a single push
- Resolve review threads (mark resolved) only AFTER the push succeeds — not while fixes are still local
- Do NOT comment just to say "polling" or "checking in" — those are noise
- Do NOT comment if nothing has changed since your last comment
- Batch related responses into a single comment
- When pushing fixes, include `[autofix]` prefix so humans can spot automated pushes

## CI Fix Workflow

```
1. Check CI status (see command reference)
2. Identify failing check(s) or job(s)
3. If pipeline is still running, wait for completion
4. For each failure:
   a. Get logs (see command reference)
   b. Diagnose root cause:
      - Lint failure? Run the linter locally, fix formatting, push
      - Compilation error? Can you see the error clearly? Fix and push
      - Test failure? Read the test output. Only fix if the fix is obvious
      - Flaky test? Re-run once. If it fails again, report to user
   c. If fix is straightforward (≤ 3 lines, obvious intent):
      - Make the fix
      - Push with message "ci: fix [what was fixed]"
      - Re-check CI
   d. If fix is not obvious:
      - DO NOT guess
      - Report to user with the failure log snippet and your assessment
5. If no failures remain, mark CI as resolved
```

### GitLab CI specifics

GitLab pipelines are structured as stages → jobs. Use:

```
glab ci list --mr <!>           # list pipeline jobs
glab ci trace <job-id>          # view job logs
glab ci retry <job-id>          # retry a failed job
```

GitLab CI may have manual stages (environments, deployments). Only act on automatic stages; skip manual ones unless instructed.

## Merging

Only merge when:
- All requested reviewers have approved (or review requirement is met)
- All CI checks are green
- No merge conflicts
- User gave explicit merge permission OR you have standing merge authority

| Platform | Merge command |
|---|---|
| GitHub | `gh pr merge <#> --squash --delete-branch` |
| GitLab | `glab mr merge <!> --squash` |

For GitLab, if "Delete source branch" is not a project default, add `--remove-source-branch`.

## Resolving complexity

| Complex PRs (many files, large diff) | Simple PRs (small change, clear intent) |
|---|---|
| Look for split opportunities (can this be 2-3 smaller PRs?) | Merge quickly after approval + green CI |
| Pay extra attention to review feedback — harder to re-review | Fix CI failures aggressively |
| Log what you checked so user can scan | Default: merge yourself |

## Stop conditions

Stop polling and report to user when:
- User returns / says to stop
- All PRs merged or closed
- A CI failure repeats 3 cycles without resolution
- A comment requires human judgment you don't have
- You detect a merge conflict you can't resolve cleanly

## Common mistakes

| Mistake | Fix |
|---|---|
| Polling once and stopping | The core of this skill is the LOOP. Keep going unless a stop condition fires. |
| Commenting "I checked, everything looks good" every cycle | Only comment when you took action or when asked for status. |
| Merging after approval without checking CI | Approval ≠ ready to merge. Always check CI first. |
| Fixing a test you don't understand | "Obvious fix" means you can explain WHY. If you can't, don't fix. |
| Pushing after each comment fix | Fix ALL issues first, then push once. |
| Resolving review threads before pushing | Mark threads resolved only AFTER the push succeeds. |
| Re-pushing without addressing all feedback | Triage ALL unaddressed comments before pushing. |
| Using the wrong CLI tool | Detect platform first (see Platform detection). |
| Not tracking which comments are new | Compare against your last poll's comment timestamps/IDs. Don't re-answer old comments. |
| Treating GitLab manual jobs as failures | Skip manual stages (deploy, review apps). Only act on automatic CI failures. |

## Red Flags — STOP and ask user

- CI failure log is >50 lines of unfamiliar code
- A reviewer asks for an architectural change
- You've pushed 3+ fix commits and CI still fails
- A comment contradicts another reviewer
- Merge conflicts involve files you didn't originally touch
- User said "stay on this" or "stop" — their word overrides this skill
- Platform detection fails or returns ambiguous results (multiple remotes, self-hosted both)