• Reviewing any category yourself instead of dispatching
• Dispatching subagents sequentially instead of in parallel
• Skipping a subagent because "the diff doesn't look like it has X"
• Claiming review passed without reading subagent findings
• Editing code during review (review reads, doesn't write)
• Falling back to self-review because a subagent failed
• Hiding subagent failures in output (must surface in sticky header)
• Marking prior findings as

  ✅ Fixed

  without a verification note from subagent
• Publishing inline comments before merging findings (dispatch → merge → publish)

• Reviewing a PR/MR diff and producing structured findings
• Security / logic / performance scans on code changes
• Spec compliance verification when spec exists
• Organizing findings with severity + blast radius + confidence
• Posting findings to GitHub PR as sticky summary + inline comments

• Writing or improving PR descriptions
• Design review requiring business judgment about scope or direction
• Writing the actual code/diff
• Deep CVE / supply-chain / OWASP sweep
• Writing release notes / CHANGELOG
• End-user / UX review (use /qa or /design-review)
• Auto-approving or auto-merging (produce findings only; humans merge)

pr

<owner>/<repo>#<N>

Exception:

mode: local

does not require

pr

(no GitHub side effects). See Local Mode.

mode

auto

full

incremental

local

dry-run

true

false

false

base

origin/main

last_sha

spec

has_spec

• Path:

  spec: docs/specs/payment-v2.md

• URL:

  spec: https://confluence.example.com/payment-v2

• Inline:

  spec: this PR implements PCI DSS v4.0 logical isolation

• Multiple:

  spec: design doc at X, acceptance criteria in Jira ABC-123

test direction

• Approach:

  unit only

  /

  integration required

  /

  e2e required

  /

  no test needed

• Location: expected test file path
• Focus: scenario or case the test should cover

context

• Business risk: "this endpoint is internal-admin only"
• Domain rules: "tenant_id is required"
• Known trade-offs: "we're aware of the N+1, will fix next sprint"
• Environment constraints: "CDE service, security findings cannot be downgraded"
• Hotfix narrowing: "hotfix — only check critical security"
• Cross-PR coupling: "ships together with PR #1234"

mode: local

base

last_sha

digraph mode {
  "mode input" [shape=box];
  "Has sticky?" [shape=diamond];
  "last_sha reachable?" [shape=diamond];
  "Same as HEAD?" [shape=diamond];
  "incremental" [shape=box, style=bold];
  "full" [shape=box, style=bold];
  "local" [shape=box, style=bold];
  "noop (report no-change)" [shape=box, style=bold];

  "mode input" -> "Has sticky?" [label="auto"];
  "mode input" -> "incremental" [label="incremental (forced)"];
  "mode input" -> "full" [label="full (forced)"];
  "mode input" -> "local" [label="local (forced)"];
  "Has sticky?" -> "last_sha reachable?" [label="yes"];
  "Has sticky?" -> "full" [label="no"];
  "last_sha reachable?" -> "Same as HEAD?" [label="yes"];
  "last_sha reachable?" -> "full" [label="no\n(force-push?)"];
  "Same as HEAD?" -> "noop (report no-change)" [label="yes"];
  "Same as HEAD?" -> "incremental" [label="no"];
}

gh api repos/<owner>/<repo>/issues/<N>/comments \
  --jq '.[] | select(.body | contains("<!-- pr-review:sticky -->")) | {id, body}'

• <!-- pr-review:sticky -->

  — locator

• <!-- pr-review:sha=<commit> -->

  — last reviewed HEAD

git cat-file -e <last_sha> 2>/dev/null && echo reachable || echo unreachable

full

> ⚠️ Prior review base `<last_sha>` is not reachable (force-push?). This iteration is a full re-review.

last_sha == HEAD

pr-review: nothing new since <last_sha>. Skipping. Use mode=full to force a re-review.

Caveat — calling from the same dev session that wrote the code (author-as-reviewer bias): pr-review's 4-subagent dispatch is isolated by design — finding generation is robust even when called from the author's session. But the downstream

modify / wontfix / defer

verdict on each finding is NOT covered by this isolation. If the same session that wrote the code also reasons about which findings to wontfix, author-narrative bias compounds — framing a diff as "bug-free" produces the strongest detection drop among framing conditions tested across 6 LLMs (Mitropoulos et al., Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review, arXiv:2603.18740). Treat local-mode findings as advisory in dev sessions; do NOT auto-execute verdicts in main session. A proper dev-stage verdict loop needs a separate Deriver-pattern verdict-subagent (not built yet — see

pr-babysit/SKILL.md

§ 4.6 "When NOT to use" for the equivalent caveat on Wontfix Template).

• mode: local

  (required to enter this mode)

• base: <ref>

  (required — e.g.

  origin/main

  )

• last_sha: <sha>

  (optional — if provided, runs incremental on

  <last_sha>..HEAD

  and still reads

  <base>...HEAD

  for cumulative context that subagents need for prior-finding verification)

• spec

  ,

  test direction

  ,

  context

  — same semantics as default mode

pr

• No

  last_sha

  → full diff:

  git diff <base>...HEAD

  (three-dot — topic-only changes)
• With

  last_sha

  → incremental: subagents see both

  <base>...HEAD

  and

  <last_sha>..HEAD

  ; they report findings only inside the incremental window plus verification status for prior findings (caller must pass prior findings too — see below)

• prior_findings

  : array of objects with

  {id, slug, file, line, category, severity, justification, summary}

  — same shape as findings JSON output (see below)

• prior_fix_range

  :

  <first-fix-sha>^..<last-fix-sha>

  — the commits that addressed iter (N-1) findings, used by the threshold's drop signal (B)

last_sha

prior_findings

• HARD-GATE: still dispatch 4 parallel subagents; main session never reviews
• Capability flags (has_spec, has_repo, is_trivial)
• Finding Inclusion Threshold (Reachable / Precedent / Asymmetric / Historical + drop signals A/B/C/D)
• Severity Merge Rule (4 steps + P-code mapping)
• Dedup between subagent findings
• Subagent failure → if all 4 fail, report failure to caller; never self-review

• Sticky comment build / markdown rendering
• Inline comment markdown / GitHub Review API call
• Sticky discovery via

  gh api

• last_sha derivation from sticky body (caller passes it)
• Noop case (caller decides whether to re-invoke; if

  last_sha == HEAD

  and caller still invokes, return

  findings: []

  + a

  status: "noop"

  )

security-reviewer-prompt.md

staff-engineer-prompt.md

sdet-prompt.md

spec-auditor-prompt.md

• Diff (full in

  full

  mode;

  <last_sha>..HEAD

  in

  incremental

  mode)
• Capability flags (has_spec, has_repo, is_trivial)
• Mode (

  full

  /

  incremental

  )
• Their relevant inputs only (spec content for spec-auditor, test direction for sdet)
• In

  incremental

  mode (dispatcher MUST provide all three):
  • Prior findings JSON (subagent's own category scope only)
  • Prior

    Checked & clean

    slugs for drift spot-check

  • prior_fix_range

    :

    <first-fix-sha>^..<last-fix-sha>

    — git range covering the commits that addressed iter (N-1) findings. Subagent uses this to apply drop signal (B) self-introduced surface. In single-commit-per-iter cases this collapses to

    <last_sha>..HEAD

    . If the dispatcher cannot determine the range (e.g. force-push, squash-merge of iter N-1 commits) → fall back to

    full

    mode and announce in sticky; do NOT invoke incremental mode without

    prior_fix_range

• NO conversation history, NO session context, NO prior subagent findings from this run

security-reviewer-prompt.md

staff-engineer-prompt.md

sdet-prompt.md

spec-auditor-prompt.md

• 1 subagent fails → continue with rest; sticky header shows

  ⚠️ Partial — <subagent> failed

• 2+ fail → continue with surviving findings; sticky header shows

  ⚠️ Partial — N/4 subagents failed: <names>

• ALL fail → report failure to user, do not publish, never self-review

[<category-id> <category-name>] <file>:<line_start>-<line_end>
Severity: 🚨 | ⚠️ | 💡 | ❓
Confidence: high | medium | low
Blast: Local | Module | Cross-service | Data layer
Justification: Reachable | Precedent | Asymmetric | Historical

Evidence: <verbatim diff line(s) — cite-or-drop rule>
Failure mode: <one-line — what breaks if shipped as-is>
Mitigation: <one-line — fix action; cite test path when test coverage is part of the fix>
Details: <optional — multi-line narrative, repro steps, code patch. Use only when Failure mode genuinely needs more than one line>
Notes: <optional — only if severity differs from default>

• Failure mode

  — concrete bug / breach / drift consequence. Forces severity calibration: if you cannot describe what goes wrong in one line, you do not have a finding.

• Mitigation

  — actionable fix. When the finding's resolution involves test coverage, name the test file and case (e.g.

  add assert in foo_test.py:42 'rejects empty input' case

  ).

• Details

  — escape hatch for findings whose explanation cannot fit one line (e.g. multi-step race, cross-file impact chain). Keep

  Failure mode

  and

  Mitigation

  as one-liners regardless; put narrative here.

• Justification

  — required class declaring why the finding is worth emitting. See Finding Inclusion Threshold below. Findings that cannot commit to one of the four classes MUST NOT be emitted as standalone findings; batch into a Q-class hygiene followup instead.

N/A categories: [<list>]

Spec quote:

Code quote:

Evidence:

Failure mode

Evidence:

• security-reviewer-prompt.md

  § Finding Inclusion Threshold

• staff-engineer-prompt.md

  § Finding Inclusion Threshold

• sdet-prompt.md

  § Finding Inclusion Threshold

• spec-auditor-prompt.md

  § Finding Inclusion Threshold

prior_fix_range

1. Base severity — assigned by subagent at finding emission (emoji form)
2. Confidence demote —

   confidence: low

   → demote to ❓ Question (terminal, no further escalation)
3. Blast escalate —

   blast: cross-service

   or

   blast: data-layer

   → escalate one level (max 🚨 Blocker). Skipped if step 2 already demoted.
4. Context adjust — overrides from context input (e.g. "CDE service: security cannot downgrade") applied last
5. Final severity — result after all four steps
6. Map to P-code for output (dispatcher does this; subagents emit emoji severity only):

Severity adjustments

<details>

• Same

  file:line

  + same category → keep highest base severity, attribute to all reporting subagents
• Same issue described differently across subagents → merge into one finding with combined notes
• Cross-cutting (e.g. staff-eng AND sdet both flag missing test for SQL injection) → keep both, dispatcher cross-references

1. Sticky comment — single issue comment on the PR; updated in place across iterations (PATCH same comment id)
2. Inline review comments — one GitHub review submission (

   event=COMMENT

   ) containing one comment per P0 / P1 / P2 finding; Q findings stay in the sticky

🔴 Blocking issues found

⚠️ Review before merge

✅ Approved with notes

✅ Approved

⚠️ Partial — <details>

APPROVE

REQUEST_CHANGES

[<code> <name>]

• [E3 Conditional side effects]

  →

  state-consistency

  (use semantic slug, not the literal name when one is more reviewer-meaningful)

• [S3 Secret / credential]

  →

  secrets-handling

• [T1 Test coverage gaps]

  →

  missing-coverage

• [C4 Business rule alignment]

  →

  decision-conflict

• <id> <P-code>

  <slug>

  — <file>:<line>
• ...

<slug>

• <slug>

  : <one-line evidence — what specific patterns were verified clean, or which grep / file-read confirmed>
• ...

pr-review

<base>..<HEAD>

<last_sha>

Rules:

- Shape narrative mandatory when ≥2 findings; optional for 0-1
- `📋 Currently open` rendered **flat** (no `<details>`) when ≥1 finding is not yet `Likely fixed`; one bullet per finding, sorted P0→P1→P2→Q then by file path. Omit the section entirely when all findings are closed (avoid empty heading)
- `📊 Overview by category` always in `<details>` (collapsed); rows omitted where P0/P1/P2/Q are all zero. Collapsed by default — summary line already conveys totals; the table is for drill-down only
- `📍 Inline comments` line shown when ≥1 P0/P1/P2 finding posted inline; omit otherwise
- `Severity adjustments` rendered **flat** (no `<details>`) when any adjustment exists — discipline requirement, never silent
- `🔄 Last iteration changes` rendered **flat** in incremental mode; shows ONLY this iter's verifications (`<last_sha>..<HEAD>`), never cumulative across older iterations. Audit trail for older iters lives in git history (commits + prior inline comment threads), not in the sticky
- `Spec gap questions` always in `<details>` (collapsed) — verbose; secondary to actionable findings
- `Checked & clean` always in `<details>` (collapsed) — count is the load-bearing signal; expand for trust calibration

event=COMMENT

**![<P-code>](https://img.shields.io/badge/<P-code>-<color>) <slug>**

**Failure mode**: <one-line>

**Mitigation**: <one-line; cite test path when applicable>

<details><summary>Evidence</summary>

```diff
<verbatim diff line(s)>
```

</details>

<sub>blast: <Local|Module|Cross-service|Data layer> · <reversible|not reversible> · confidence: <high|medium|low> · justification: <Reachable|Precedent|Asymmetric|Historical></sub>

<!-- pr-review:finding-id=#<n> -->
<!-- pr-review:justification=<Reachable|Precedent|Asymmetric|Historical|Hygiene> -->

justification

pr-babysit

Hygiene

Hygiene

• P0

  →

  red

• P1

  →

  orange

• P2

  →

  yellow

reversible

• reversible

  — code-only change, additive feature, refactor without state migration

• not reversible

  — destructive migration, breaking contract change, irreversible side effect (sent message, deleted data)
• omit if ambiguous (don't guess)

<Blast>

1. <numbered question>
2. ...

Q findings do **not** become inline comments — they're often cross-file conceptual questions, pinning to a line misleads.

dry-run: true

• Print sticky body markdown to console (with markers)
• Print inline payload as JSON
• Skip all

  gh api

  writes
• Useful for first-time use, debugging, or auditing output before publishing

Agent

references/X.md

references/

• Finding Inclusion Threshold (Justification classes + drop signals A/B/C/D) — identical wording across all 4 subagent prompts; SKILL.md only points to them
• Race-class Finding Metadata (

  [window=..., damage=..., recovery=...]

  meta tag spec) — identical across

  staff-engineer-prompt.md

  +

  security-reviewer-prompt.md

  ; pr-babysit's Gate B parser depends on identical syntax

<!-- keep-in-sync: ... -->

references/

328b73b8

• Don't auto-approve or auto-merge — produce findings; merge belongs to humans
• Lean conservative — low-confidence findings always demote to ❓ Question (Q)
• Spec gaps don't block review — mark Q for spec author, proceed with code findings
• Severity downgrades must be visible — flat section in sticky, never

  <details>

• Don't auto-grep for spec location — use only what the user provides
• Subagent reports are advisory — dispatcher applies merge rule and dedup, not subagents
• Subagent failure must be surfaced — sticky header carries the partial-mode warning; never silent
• Prior findings: hedge on "fixed" — always

  Likely fixed

  , never bare

  Fixed

  ; line-moved ≠ behaviour-fixed
• Force-push aware — when last_sha is unreachable, fall back to full + announce in sticky
• Output language is adaptive — PR-published prose follows the PR description's language; markers / titles / field labels / keywords / terms stay English. See Output Language
• Local mode is JSON-only — no markdown, no sticky, no inline; caller (e.g. a supervisor session) consumes findings JSON and drives its own follow-up loop