Pr Sheriff

1. Load the config:

cat $GT_ROOT/.beads/pr-sheriff-config.json

This contains crew mappings per repo and contributor policies (trust tiers, firewalled contributors, bot auto-merge rules). Only scan repos within your scope (see Repo Scope above).

2. Follow the formula steps in order:

gt formula show mol-pr-sheriff-patrol

The formula defines a 7-step workflow:

3. For each step, read the full description:

gt formula show mol-pr-sheriff-patrol  # Shows all steps with descriptions

Key References

• Patrol formula: mol-pr-sheriff-patrol (town-level)
• Crew review formula: mol-pr-crew-review (dispatched to crew)
• Deep review formula: mol-pr-deep-review (dispatched for NEEDS-HUMAN)
• Config: $GT_ROOT/.beads/pr-sheriff-config.json

Contributor Policy Tiers

Loaded from config. Current tiers:

Category Decision Tree

Draft? → SKIP
Contributor firewalled? → NEEDS-HUMAN (deep review)
Dependabot patch bump + CI green? → EASY-WIN
<50 lines, obvious bug/doc/test fix? → EASY-WIN
Security/architecture/API change? → NEEDS-HUMAN
Multi-concern PR? → NEEDS-HUMAN
100+ lines new feature? → NEEDS-CREW or NEEDS-HUMAN
Everything else → NEEDS-CREW

Deep Review Evaluation Framework (NEEDS-HUMAN)

The deep review formula (mol-pr-deep-review) applies six lenses:

1. Plugin/integration fit — core vs plugin/formula/integration?
2. Tech-debt weight — complexity justified by user breadth?
3. Contributor track record — first-time, repeat, or firewalled?
4. ZFC compliance — structural checks, not string heuristics?
5. Problem validity + solution fit — real problem, right solution?
6. Splitability — can good parts be cherry-picked from bad?

Final verdicts: MERGE | CHERRY-PICK | REWORK | REIMPLEMENT | CLOSE

Output Format

For each PR, print a recommendation block:

### PR #<num>: <title>
Author: <login> | +<additions>/-<deletions> | <changedFiles> files

**Category**: EASY-WIN | NEEDS-CREW | NEEDS-HUMAN | SKIP

**Analysis**:
<1-3 sentences explaining the change and why it fits this category>

**Recommendation**:
<specific action>

Summary Output

## PR Sheriff Patrol Summary — <date>

**Easy-wins merged**: N
**Crew-reviewed and merged**: N
**Sent back for rework**: N
**Closed**: N
**Still pending**: N

Dispatching Work: Use Ephemeral Beads

When creating beads to track fix-merge work for polecats or crew, use ephemeral beads (wisps) rather than persistent beads. PR review/fix-merge tasks are orchestration scaffolding — they exist to give a polecat something to hook and track, not to create a permanent record.

Ephemeral beads are the right trade-off: they give polecats and crew trackable work items without polluting Dolt's permanent ledger with one-off orchestration noise. If/when beads are exported to permanent ledgers, review-task wisps won't clutter the history.

# Ephemeral bead for fix-merge dispatch
bd new -t task "Fix-merge PR #1234: description" -p 2 -l pr-review \
  --wisp-type patrol

# vs persistent (avoid for orchestration work)
bd new -t task "Fix-merge PR #1234: description" -p 2 -l pr-review

The --wisp-type patrol flag marks it as ephemeral orchestration work that the reaper will eventually clean up. The polecat/crew member can still hook it, work it, and close it normally.

CRITICAL Rules

• All output is printed inline. Do NOT post comments to GitHub.
• The overseer decides what gets posted externally.
• Contributor-friendly: help contributors get to the finish line.
• Use Co-authored-by trailer when fixing up contributor work.