@clipboard-health/ai-rules 2.25.0 → 2.26.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clipboard-health/ai-rules",
-  "version": "2.25.0",
+  "version": "2.26.0",
   "description": "Pre-built AI agent rules for consistent coding standards.",
   "keywords": [
     "ai",

package/rules/common/coreLibraries.md

@@ -34,7 +34,6 @@ When a bug traces into a `@clipboard-health/*` library, read the source code in
 - **playwright-reporter-llm**: Playwright reporter that outputs structured JSON for LLM agents. Minimal console output, flat schema, easy to filter to failures.
 - **rules-engine**: A pure functional rules engine to keep logic-dense code simple, reliable, understandable, and explainable.
 - **testing-core**: TypeScript-friendly testing utilities.
-- **tribunal**: Structured second opinions from advocate, skeptic, analyst, and deliberator LLM perspectives.
 - **util-ts**: TypeScript utilities.
 
 <!-- END: Auto-generated by ./populateLibraries.ts -->

package/skills/babysit-pr/SKILL.md

@@ -27,9 +27,9 @@ This skill always runs exactly one pass. It never waits or repeats internally. F
 
 The skill uses two sentinels. Each is a visible footer line wrapped in `<sub>` (a 🤖 mark plus the token in `<code>`).
 
-**Addressed sentinel**: `<sub>🤖 <code>babysit-pr:addressed v1 core@3.8.0</code></sub>`. Appended on its own line at the end of every reply the skill posts (both thread replies and the review-body summary); this is how re-runs know which threads and review-body comments are already handled. Dedupe matches the version-agnostic substring `babysit-pr:addressed v1` followed by a space (also matches legacy `<!-- babysit-pr:addressed v1 ... -->` sentinels). Grep `babysit-pr:addressed v1` for any version; add `core@3.8.0` for a specific one.
+**Addressed sentinel**: `<sub>🤖 <code>babysit-pr:addressed v1 core@3.9.0</code></sub>`. Appended on its own line at the end of every reply the skill posts (both thread replies and the review-body summary); this is how re-runs know which threads and review-body comments are already handled. Dedupe matches the version-agnostic substring `babysit-pr:addressed v1` followed by a space (also matches legacy `<!-- babysit-pr:addressed v1 ... -->` sentinels). Grep `babysit-pr:addressed v1` for any version; add `core@3.9.0` for a specific one.
 
-**Follow-up sentinel**: `<sub>🤖 <code>babysit-pr:followup v1 core@3.8.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up (see the Scope subsection and the Defer verdict in step 6). Grep `babysit-pr:followup` across PR conversation JSON to enumerate deferred items. This sentinel is additive — the post-reply scripts still append the `addressed` sentinel at the end, so a deferred thread is correctly machine-classified as addressed (the skill _has_ handled it — by deferring). Human reviewers and future sweeps distinguish deferred from resolved by looking for the follow-up sentinel.
+**Follow-up sentinel**: `<sub>🤖 <code>babysit-pr:followup v1 core@3.9.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up (see the Scope subsection and the Defer verdict in step 6). Grep `babysit-pr:followup` across PR conversation JSON to enumerate deferred items. This sentinel is additive — the post-reply scripts still append the `addressed` sentinel at the end, so a deferred thread is correctly machine-classified as addressed (the skill _has_ handled it — by deferring). Human reviewers and future sweeps distinguish deferred from resolved by looking for the follow-up sentinel.
 
 **Sentinel recency rules.** The script emits a per-thread `activityState` with three values:
 
@@ -280,7 +280,7 @@ Body templates (the script appends the `addressed` sentinel if missing):
 - **Agree**: `Addressed in <commit-url>. <one-line what-changed>.`
 - **Disagree**: `Leaving current behavior. <reasoning>.`
 - **Already fixed**: `Already handled by <commit-url-or-file:line>. <brief pointer>.`
-- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>babysit-pr:followup v1 core@3.8.0</code></sub>`
+- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>babysit-pr:followup v1 core@3.9.0</code></sub>`
 
 For Defer replies, include the follow-up sentinel on its own line as shown. The script will append the `addressed` sentinel after it on its own line, so the final body ends with the follow-up sentinel followed by a blank line followed by the `addressed` sentinel — `grep babysit-pr:followup` finds the deferral and `grep babysit-pr:addressed` still marks the thread handled for dedupe.
 
@@ -296,7 +296,7 @@ The PR-level summary should:
 
 - Group by source. Use `## Review-body findings` for step-7 work and `## Conversation-tab comments` for step-6b work. Omit a section if its list is empty.
 - Inside each section, group verdicts under **Agree / Disagree / Already fixed / Deferred (out of scope)** subheadings. Omit a subheading if its list is empty.
-- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>babysit-pr:followup v1 core@3.8.0</code></sub>` so grep catches them individually.
+- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>babysit-pr:followup v1 core@3.9.0</code></sub>` so grep catches them individually.
 - Include the commit URL for fixes.
 - End with a fenced fingerprint block listing every current fingerprint — addressed and deferred — one per line. Include both `reviewBodyComments[].fingerprint` (whole-body, one per automated review) and `activeIssueComments[].fingerprint` (per Conversation-tab comment). Future runs dedupe by matching these against `priorBabysitSentinels`.
 

package/skills/babysit-pr/scripts/_sentinel.sh

@@ -9,7 +9,7 @@
 # substituted at build time by embedPluginVersion.mts.
 
 SENTINEL_PREFIX='babysit-pr:addressed v1 '
-SENTINEL='<sub>🤖 <code>babysit-pr:addressed v1 core@3.8.0</code></sub>'
+SENTINEL='<sub>🤖 <code>babysit-pr:addressed v1 core@3.9.0</code></sub>'
 
 # Bot author allowlist (JSON array literal). Used by unresolvedPrComments.sh
 # as a fallback when GraphQL's `author.__typename == "Bot"` misses a GitHub

package/skills/commit-push-pr/SKILL.md

@@ -47,7 +47,7 @@ Script paths in this procedure are written as `scripts/...`, relative to this SK
 6. Check for an existing PR with `gh pr view`.
 
    PR title format: conventional-commit type + description, with no scope, plus the Linear ticket in parentheses at the end when one applies (e.g., `feat: add resume command (STAFF-123)`). This differs from the commit subject, which keeps its scope. Derive the ticket from the branch name, commit body, or session context; omit the parenthetical when no ticket applies.
-   - No PR: create with `gh pr create` using the PR title format above. Description = the PR body shape above, followed by the session footer line if known and the agent footer `<sub>🤖 <code>commit-push-pr:created v1 core@3.8.0</code></sub>` on its own line.
-   - PR exists: if the title doesn't match the format above, correct it with `gh pr edit --title`. Refresh the body via `gh pr edit --body` so (a) the new commit's changes are reflected in the prose while existing `## Summary`, `## Validation`, and `## Notes` sections are preserved unless clearly stale, (b) any known session footer line is appended if missing, never removing or rewriting existing `Agent session: ...` or `Agent session ID: ...` lines, and (c) any existing footer carrying the substring `commit-push-pr:created v1` is preserved verbatim, appending `<sub>🤖 <code>commit-push-pr:created v1 core@3.8.0</code></sub>` only if absent. Then report the URL.
+   - No PR: create with `gh pr create` using the PR title format above. Description = the PR body shape above, followed by the session footer line if known and the agent footer `<sub>🤖 <code>commit-push-pr:created v1 core@3.9.0</code></sub>` on its own line.
+   - PR exists: if the title doesn't match the format above, correct it with `gh pr edit --title`. Refresh the body via `gh pr edit --body` so (a) the new commit's changes are reflected in the prose while existing `## Summary`, `## Validation`, and `## Notes` sections are preserved unless clearly stale, (b) any known session footer line is appended if missing, never removing or rewriting existing `Agent session: ...` or `Agent session ID: ...` lines, and (c) any existing footer carrying the substring `commit-push-pr:created v1` is preserved verbatim, appending `<sub>🤖 <code>commit-push-pr:created v1 core@3.9.0</code></sub>` only if absent. Then report the URL.
 
 7. End with one short text response: branch name and the full PR URL (e.g., `https://github.com/clipboardhealth/core-utils/pull/123`). Never use shorthand like `repo#123` — always output the complete URL.

package/skills/in-depth-review/SKILL.md

@@ -0,0 +1,491 @@
+---
+name: in-depth-review
+description: Multi-agent code review of the current branch or a PR — parallel engineering, minimalist, conventions, and AntiSlop reviewers plus conditional security, database, and frontend specialists that debate, then a synthesized review posted as anchored PR comments. Use when the user asks for a deep, thorough, or multi-perspective review, reviews a large or high-stakes diff, or runs /in-depth-review [PR-number-or-URL]. For small diffs or a quick single-pass review, use simple-review instead.
+---
+
+# In-Depth Review
+
+Run a multi-agent code review on the current branch _or_ on a PR identified by argument. By default dispatches four parallel reviewers (engineering+customer, minimalist, conventions, anti-AI-slop) and conditionally adds up to three domain specialists (security, database, frontend) when the diff touches their surface. The first-principles adversarial agent (Agent A) is **opt-in** — include it only when the user explicitly asks (see Invocation). Agents review in parallel, debate once, and the main agent moderator-filters and synthesizes a report. Author vs reviewer mode adapts the post-review flow.
+
+## Invocation
+
+- **`/in-depth-review`** — review the current branch (resolves the open PR for the branch if any, otherwise diffs against the default branch).
+- **`/in-depth-review <PR-number-or-URL>`** — fast path for reviewing someone else's PR while sitting on `main` (typical entry from Claude Desktop in code mode on a worktree). Skips the local branch checkout, fetches diff and metadata via `gh`, forces **reviewer mode**, and skips the plan/execute path. Accepts either a bare number (resolved against the current repo) or a full GitHub PR URL (which also identifies the owner/repo, useful when the worktree's remote differs).
+
+### Agent roster
+
+| Letter | Name        | Role                                  | Default state                                |
+| ------ | ----------- | ------------------------------------- | -------------------------------------------- |
+| A      | Adversarial | First-principles adversarial          | Opt-in only (`with adversarial`, `+A`, etc.) |
+| B      | Engineering | High engineering standards + customer | Always on                                    |
+| C      | Minimalist  | Smallest-diff posture                 | Always on                                    |
+| D      | Conventions | Repo-rules / docs                     | Always on                                    |
+| E      | Security    | Security & API surface                | Conditional (auth/route/contract files)      |
+| F      | Database    | DB schema, queries, migrations        | Conditional (migration/schema/model files)   |
+| G      | Frontend    | FE conventions & UX correctness       | Conditional (FE files)                       |
+| H      | AntiSlop    | Anti-AI-bias / pushback on slop       | Always on                                    |
+
+**Refer to agents by name in everything the user sees** (Summary, Actionable items, Raised-by lines, Disagreements, Withdrawn). The letter is a compact prefix for finding IDs (`B1`, `C3`, `Adversarial`/`A1`, …) and a shorthand inside this document — never the only label in user-facing prose. The Round 2 `original_author` field stores the **name**, not the letter.
+
+### Agent A (first-principles adversarial) is opt-in
+
+The Adversarial agent (A) is skipped by default. Include it only when the user's invocation contains a clear opt-in phrase such as `with adversarial`, `with agent a`, `include adversarial`, `add the adversarial agent`, `+A`, or equivalent. If the user gives a more ambiguous instruction (e.g. "run the full review"), ask once whether to include the Adversarial agent before dispatching. Record the decision (`agent_a_enabled: true|false` + the phrase that triggered the opt-in, if any) in `/tmp/in-depth-review-meta.json` and surface it in the Summary so the user can see what ran.
+
+## Scope
+
+Two entry paths:
+
+### Path A — PR-argument fast path (when an argument is provided)
+
+- Parse the argument: bare integer → use current repo (`gh repo view --json nameWithOwner --jq .nameWithOwner`); URL → extract `<owner>/<repo>` and `<N>` from the URL.
+- Do **not** check out the PR branch. Operate from whatever the working directory is (typically `main` in a worktree). Convention/file reads happen against a verified-fresh ref — see **Freshness preflight** below.
+- Mode is **locked to reviewer**. Skip mode detection.
+
+Gather in parallel:
+
+```bash
+gh pr view <N> --repo <owner>/<repo> --json number,url,title,body,baseRefName,author,headRefOid,headRepository,files
+gh pr diff <N> --repo <owner>/<repo>
+gh api user --jq .login
+```
+
+Persist:
+
+- Diff stdout from `gh pr diff` → `/tmp/in-depth-review-diff.patch`.
+- `pr.title + pr.body` → `/tmp/in-depth-review-context.md`.
+- `pr.files[].path` → `/tmp/in-depth-review-files.txt`.
+- Meta (PR number/url/baseRefName/author, viewer login, head SHA, owner/repo, mode=`reviewer`, conditional-agent set after classification) → `/tmp/in-depth-review-meta.json`.
+
+If `pr.author.login == viewer.login`, still proceed in reviewer mode (the user explicitly asked for the PR-arg path; honor it) but flag this in the synthesis Summary so the user can switch to a manual `/in-depth-review` run on their checkout if they meant to implement.
+
+### Path B — current-branch path (no argument)
+
+- If there is an open PR for the current branch, review that PR. Base = `baseRefName`, diff = `git diff $base...HEAD`. Capture PR title + body as context.
+- Otherwise, review the current branch vs the default branch (`main`, fall back to `master`). Capture `git log --format='%h %s%n%n%b' $base..HEAD` as context.
+- **Never** review uncommitted working-tree changes. If the branch has no diff vs base, stop and report.
+
+Gather in parallel:
+
+```bash
+git rev-parse --abbrev-ref HEAD
+git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'
+gh pr list --head "$(git branch --show-current)" --state open --json number,url,title,body,baseRefName,author,headRefOid
+gh api user --jq .login
+gh repo view --json nameWithOwner --jq .nameWithOwner
+git diff --name-only "$base"...HEAD
+```
+
+Determine **mode**:
+
+- PR exists and `pr.author.login == viewer.login` → **author mode**.
+- PR exists and authors differ → **reviewer mode**.
+- No PR exists → **author mode** (reviewing your own pre-PR branch).
+
+Persist context so subagents read it from disk:
+
+- Diff → `/tmp/in-depth-review-diff.patch`
+- Context (PR body or commit log) → `/tmp/in-depth-review-context.md`
+- Changed-file list → `/tmp/in-depth-review-files.txt`
+- Mode + repo metadata (PR number, url, base, head SHA, author, viewer, owner/repo, list of conditional agents that will run, verified-fresh `context_ref` from the freshness preflight) → `/tmp/in-depth-review-meta.json`
+
+## Freshness preflight (runs before Diff classification — both paths)
+
+Stale local state is the #1 cause of false-positive findings: it produces "evidence" of bugs that were already fixed on `main`. Before dispatching any agent, the main agent **must** verify that the ref it tells subagents to read for context is current with the remote, and pass that ref into subagent prompts so agents read code via `git show <ref>:<path>` and `git grep ... <ref> -- <paths>` rather than the worktree filesystem.
+
+Run this preflight on the **primary repo** (the one containing the diff under review):
+
+```bash
+git fetch origin "$base" --quiet 2>&1 | tail -3
+git rev-parse --abbrev-ref HEAD
+git status --porcelain
+git rev-list --left-right --count "HEAD...origin/${base}"   # prints "<ahead>\t<behind>"
+git log -1 --format='%h %ci' "origin/${base}"
+```
+
+Decide `context_ref` (the ref subagents must read for repo context, distinct from the diff itself):
+
+- **Path A (reviewer mode, PR-arg):** ideal `context_ref = origin/${base}` (whatever the PR's base branch is, usually `main`). The worktree filesystem must **only** be used as `context_ref` when `HEAD == origin/${base}` AND working tree is clean AND `git fetch` succeeded.
+- **Path B (author mode, current-branch):** `context_ref = origin/${base}`. The user's local feature-branch files are the _diff_, not the _pre-PR context_; pre-PR convention/neighbor reads must come from `origin/${base}`.
+
+If any of the following are true, **stop and ask the user before continuing**:
+
+1. `git fetch origin "$base"` failed (offline, auth, repo permissions). Print the error.
+2. `HEAD` differs from `origin/${base}` (Path A only — Path B expects HEAD on a feature branch).
+3. Working tree is dirty (`git status --porcelain` is non-empty) **and** the dirty paths overlap the diff's changed-file list or any path subagents will need to read.
+4. `HEAD` is behind `origin/${base}` (any non-zero "behind" count).
+5. `HEAD` is more than a small number of commits ahead of `origin/${base}` on Path A (ahead implies the user is mid-work on a branch that isn't the PR; their worktree is not a clean main).
+
+Warn template (substitute the verified state):
+
+> Freshness check for `<owner>/<repo>` at `<worktree-path>`:
+>
+> - on branch `<HEAD-branch>` (expected `<base>` for Path A)
+> - `<N>` commit(s) ahead, `<M>` commit(s) behind `origin/<base>` (last remote commit: `<short-sha> <iso-date>`)
+> - working tree: `<clean | dirty: N file(s)>`
+>
+> Reading code from this worktree may surface findings based on stale or local-only state.
+> Reply: `proceed` (use worktree anyway and accept the risk), `use-origin` (read context via `git show origin/<base>:<path>` instead — recommended, no checkout needed), or `stop` (let me clean up and re-run).
+
+**Never** run `git checkout`, `git stash`, `git reset`, or any other state-modifying git command on the user's behalf. The skill warns and asks; the user is the only actor that resolves local state.
+
+Record the resolved `context_ref` (e.g. `origin/main`, or the literal string `worktree (stale, user accepted risk)`) in `/tmp/in-depth-review-meta.json`. Every subagent prompt must explicitly state which ref to read and how (see "Reading code in subagents" below).
+
+### Reading code in subagents
+
+When `context_ref` is `origin/<base>`:
+
+- Read repo context via `git show "${context_ref}:<path>"` (for whole files) and `git grep -n <pattern> "${context_ref}" -- <paths>` (for searches).
+- The Read tool reads the working tree, which may be stale; subagents must **prefer** `git show` for context reads. The working tree may only be read when the file isn't tracked at `context_ref` (e.g. brand-new file in the PR diff) and that fact is explicitly noted in the finding.
+
+When `context_ref` is `worktree (stale, user accepted risk)`:
+
+- Subagents may use Read on the worktree, but every finding must include a one-line "verified against: worktree-stale" caveat in the `point`, and the moderator filter must downgrade CRITICAL/MAJOR to MINOR unless the evidence is internal to the diff itself.
+
+## Cross-repo evidence policy (binding for all agents)
+
+A finding's evidence is "cross-repo" when it depends on code in any repo other than the one containing the diff (e.g. a consumer or producer in another service). Subagents must **NOT** silently read external repos — stale checkouts fabricate evidence and unverifiable paths can't be checked. Emit such findings with an `evidence_required` field and cap severity at **MAJOR** until the moderator verifies the evidence on a fresh ref; after Round 1 the moderator collects every `evidence_required` block and asks the user for access before Round 2.
+
+Read [references/cross-repo-evidence.md](references/cross-repo-evidence.md) before raising or finalizing any cross-repo finding — it has the `evidence_required` schema, the moderator's access-request prompt, the freshness rules for external repos, and `skip` handling.
+
+## Diff classification (runs before Round 1)
+
+Match the changed-file list against these path patterns. A conditional agent runs only when its pattern matches at least one changed file:
+
+- **E — Security** triggers on: any file under `routes/`, `controllers/`, `middleware*/`, files matching `auth*`, `*permission*`, `*acl*`, `*token*`, `*session*`, response serializers, OpenAPI / contract definitions, or new API endpoint files.
+- **F — Database & migrations** triggers on: `migrations/`, `*.sql`, files matching `schema*`, Mongoose/Prisma model files (`models/`, `*.model.ts`, `*.schema.ts`), repository / DAL files, or files containing query builders.
+- **G — Frontend** triggers on: `*.tsx`, `*.jsx`, `*.css`, `*.scss`, files under `pages/`, `components/`, `hooks/`, or anything importing from `react`, `@tanstack/react-query`, or a design-system package.
+
+Record the dispatched set in `/tmp/in-depth-review-meta.json` so Round 2 knows the full agent list.
+
+## Severity rubric (binding for all agents)
+
+- **CRITICAL** — realistic input causes incorrect behavior, data loss, security regression, broken contract, or a paging incident.
+- **MAJOR** — meaningful degradation of correctness/UX/observability under realistic conditions; OR a documented-convention violation with concrete downstream impact.
+- **MINOR** — cheap, concrete improvement with a named benefit.
+- **NIT** — only admissible if (a) repeats ≥2× in the diff, (b) conflicts with a documented convention, or (c) is a one-line trivial fix. Otherwise drop silently.
+
+Every finding **must** include a `failure_mode` field: one sentence on the concrete user-, oncall-, or maintainer-visible bad outcome that would occur if not fixed. Hypotheticals like "a future caller might…" do not satisfy this; such findings will be dropped during moderation.
+
+Run the litmus test on every candidate finding before keeping it: _"What is the concrete, current, product-visible cost of leaving this code in?"_ If you cannot answer in one sentence, drop the finding.
+
+### Do-not-raise list (binding)
+
+Do not surface any of:
+
+- Speculative defensiveness at trusted internal boundaries (e.g. "what if this private helper got null?").
+- Restating the obvious ("consider a comment explaining what this does").
+- Hypothetical future-caller scenarios with no current caller.
+- Style/formatting a linter or formatter already covers.
+- Test-coverage demands on trivially-verifiable code (one-line passthroughs, simple getters).
+- "Add observability" without naming a concrete failure mode it would help debug.
+- Abstract SOLID-style "consider extracting…" suggestions without a concrete failure mode.
+- Aesthetic naming preferences. Only raise names that mislead about behavior.
+
+## Rounds (hard cap: 2)
+
+### Round 1 — parallel independent reviews
+
+Dispatch all selected agents **in the same message** via the `Agent` tool with `subagent_type: general-purpose`. The default selected set is **Engineering, Minimalist, Conventions, AntiSlop** (B/C/D/H), plus **Security, Database, Frontend** (E/F/G) when triggered by classification. **The Adversarial agent (A) is dispatched only when `agent_a_enabled` is true** (see Invocation — "Agent A is opt-in"). Each agent gets the file paths above, their role brief, and permission to Read repo files for context. Do **not** let agents see each other's output in this round. **Each agent emits at most 8 findings, prioritized — not exhaustive.**
+
+**Every subagent prompt must include the following input contract verbatim** (substitute `<context_ref>` with the value resolved in the Freshness preflight):
+
+> **Context-read contract.** The verified-fresh ref for repo context is `<context_ref>`. For any file you read that is part of the primary repo's tracked content (i.e. _not_ a brand-new file in this PR's diff), use `git show "<context_ref>:<path>"` or `git grep -n <pattern> "<context_ref>" -- <paths>` rather than the Read tool on the worktree. If you read from the worktree because the file is new in the diff or untracked at `<context_ref>`, say so in the finding's `point`.
+>
+> **Cross-repo evidence contract.** If a finding's load-bearing evidence is in any repo other than this one, do NOT silently read another local checkout — those checkouts may be stale or on unrelated branches. Instead, emit the finding with an `evidence_required` field naming the repo(s) and the specific verification question, and cap your severity at MAJOR. The moderator will ask the user for verified access before Round 2 and re-dispatch you if needed.
+
+Required output per finding: `id` (`A1`, `B3`, `C2`, `D4`, `E1`, `F1`, `G1`, `H1`, …), `severity`, `file:lines`, `title` (one sentence), `point` (one short paragraph), `failure_mode` (one sentence), optional `suggested_fix` (see schema below), and optional `evidence_required` (object with `repos: string[]` and `what_to_verify: string` — required whenever the finding depends on cross-repo state).
+
+**`suggested_fix` schema** (when present): an object with two string fields, both code (not prose), preserving the file's actual indentation:
+
+```json
+"suggested_fix": {
+  "before": "<the exact current code being changed, copied verbatim from file:lines>",
+  "after":  "<the replacement code that would land at the same anchor>"
+}
+```
+
+- For a **pure deletion**, set `after` to the empty string `""`.
+- For a **pure addition** at a new line (nothing replaced), set `before` to the empty string `""` and prefix `after` with a one-line comment indicating where it lands (e.g. `// add after line 142`).
+- For a **structural change** with no clean drop-in (e.g. "move this file"), omit `suggested_fix` entirely and put the guidance in `point` / `failure_mode`.
+- Both fields must be code snippets directly usable to compute a diff. Do not include surrounding prose, do not paraphrase, and do not elide content with `// ...`. If the change is too large to inline both, omit `suggested_fix` and describe the fix in `point`.
+
+#### Always-on agents (Engineering / Minimalist / Conventions / AntiSlop) and the opt-in Adversarial agent
+
+**Adversarial (A) — First-principles. Opt-in only.** Dispatch only when the user explicitly asks (see Invocation — "Agent A is opt-in"). Skip silently otherwise. Posture: _"What is the single most important thing this PR gets wrong? Then up to 7 more, ranked."_ Question whether the change actually solves the underlying problem and whether the chosen approach is right. Challenge specific library / pattern / approach choices when they don't hold up on their own merits. Do **not** challenge foundational stack choices that are out of scope for the PR. Flag internal inconsistencies inside the diff itself. Specifically also probe:
+
+- Should this PR be split, or is it bundling unrelated tickets?
+- Is the root cause of the bug clear, and is it fixed in _every_ place it manifests?
+- Is a feature flag warranted but missing?
+- Are there old feature flags or dead references this change makes deletable?
+
+Conventions are the Conventions agent's (D) job — do not double up.
+
+**Engineering (B) — High engineering standards + customer-centric.** Posture: _"For each change, name a realistic input or condition that would expose a bug. If you cannot, do not raise it."_ Evaluate edge cases, error paths, observability, tests (coverage of real risk, not lines), high-level security (E does the deep dive when dispatched), concurrency, performance at real scale, data integrity, accessibility, UX, degraded-mode behavior, backward compatibility, on-call implications, and domain assumptions in the diff. Specifically also probe:
+
+- Async/await correctness — ordering matches the actual dependency between calls.
+- Timezone correctness in date-handling code; currency variables explicitly in minor units.
+- When API surface changed: AuthN, AuthZ, sensitive-data leakage, PII handling. Hand the deep dive to Security (E) if dispatched.
+- When a migration is in the diff: rollback strategy, backward compatibility during rolling deploy, ETL / downstream impact. Hand to Database (F) if dispatched.
+- When DB schema or queries changed: indexes for new query patterns, N+1 risk, cascade-delete semantics, data-type fit. Hand to Database (F) if dispatched.
+- Telemetry covers _business / product_ value, not only engineering surface metrics (latency / error rate).
+- Contract / backward-compatibility for any consumer-visible response shape change.
+
+Skip items that fail the realistic-input test.
+
+**Minimalist (C).** Posture: the smallest diff that ships the intent is the best diff. Identify unneeded abstractions, speculative generality, dead branches, redundant validation, defensive code at trusted internal boundaries, comments that restate code, new files / utilities that duplicate existing ones, tests that test the framework rather than behavior, flags / config knobs without a concrete caller. Specifically also probe:
+
+- Duplicated error handlers in the same scope.
+- Commented-out code or dead branches (still gated by `failure_mode`).
+
+For every "delete this" finding, `failure_mode` must state the _concrete cost of keeping the code_.
+
+**Conventions (D) — Repo-rules.** Sole owner of convention checks (backend / shared). Read `AGENTS.md`, `CLAUDE.md`, `.rules/`, `.cursorrules`, `docs/adr/` (or equivalent), package READMEs in the diff's path, and one or two neighboring files in the same service for in-practice patterns. Then check the diff for:
+
+- Preferred internal packages over third-party ones (e.g. `@clipboard-health/*`, internal `lib/*`).
+- Terminology rules (worker/workplace, not HCP/facility).
+- `lodash` removal preference.
+- `@clipboard-health/datetime` over `date-fns`, `date-fns-tz`, `moment`, `luxon`.
+- Internal `Money` package for currencies; explicit minor-units variable names.
+- Logging conventions (`longContext`, `ObjectId.toString()`, no variables in log messages).
+- Null/undefined checks via `isDefined` / `isNil` over truthy.
+- 4+ argument functions → params object.
+- Error-handling patterns in the same service (typed `ServiceResult` vs throw).
+- Test conventions, naming, file location.
+- Business-meaningful magic constants that should be named.
+- ENV access via the project's Configuration abstraction, not direct `process.env`.
+- Logging library standard for the repo (e.g. Winston) — derive from existing code, not hardcoded.
+- Pinned dependencies; lock file (`package-lock.json` / `yarn.lock`) in sync with `package.json`.
+- RESTful route shape and uniform response format within a service.
+- Internal inconsistency _within the diff itself_ (e.g. half of imports from one package family, half from upstream).
+
+Frontend conventions are the Frontend agent's (G) territory when G is dispatched. If Frontend is not dispatched (no FE files), Conventions (D) may surface FE convention drift if it appears.
+
+Tag every finding `[CONVENTION]`. Cap severity at MAJOR (only when behavior diverges as a result of the violation) or MINOR otherwise. At the top of your output, list the specific files/sources you checked.
+
+**AntiSlop (H) — Anti-AI-bias.** Posture: _"This PR may have been written or assisted by an LLM. For each addition, ask: 'is this line earning its keep, or is it pattern-matching what code is supposed to look like?' If a reasonable senior engineer wouldn't have written it, call it out and propose deleting or shrinking it."_ Your job is to push back on AI-shaped padding that the other agents are too polite to call slop. Specifically watch for, **inside the diff itself**:
+
+- **Defensive code at trusted internal boundaries.** Null / undefined guards on private helpers whose callers' types already guarantee non-null. `try` / `catch` wrapping a single call that doesn't itself throw, or that re-throws unchanged, or that "logs and swallows" without naming what to do next. Optional-chaining cascades through types that don't include optionality.
+- **Defensiveness against unrealistic product / domain scenarios.** Code that guards against situations that wouldn't actually arise when the product is used as designed. Ask the litmus question: _"In the real product flow this code participates in, what user action, system event, or upstream call could land us in this branch?"_ If the answer is "none" or "I had to invent one to justify the guard", the code is slop. Concrete shapes this takes:
+  - A `null` / `undefined` guard on an ID immediately after that ID was used to load (and find) the entity.
+  - A `null` / `undefined` / `""` / `0` branch on a field whose TypeScript type permits only one of those values, or whose Zod / class-validator schema already rejected the others at the request boundary.
+  - A re-validation of a value the request DTO already validated upstream in the same request lifecycle.
+  - A consistency check (`if (a !== b) throw`) between two fields the data model forbids being unequal.
+  - A branch for a product-impossible state — e.g. "what if the worker is assigned to two workplaces at once" when the product enforces single-active-assignment; "what if the shift end is before its start" after the schema already enforces ordering; "what if the dispute amount is negative" when the validator caps it.
+  - A retry / fallback layer around an SDK or library call that already retries or already returns a typed error you can ignore.
+  - A `catch` clause for an error class the underlying code is statically known not to throw, or that "logs and swallows" without naming what to do next.
+  - A "future-proof" code path (`if (feature === "v2")`) when there is no `v2` and no concrete ticket creating one.
+
+  Don't accept "but what if upstream changes?" as a defense — that's the hypothetical-future-caller anti-pattern. The fix when upstream genuinely changes is a typed-error / schema update in the same PR, not preemptive guards.
+
+- **Restating-the-code comments.** `// fetch the user`, `// loop through items`, `// add 1 to counter`. JSDoc on private helpers that only restates the signature. `// Note: this is important` lines. Section banners (`// === HELPERS ===`) inside short files.
+- **Empty scaffolding.** `// TODO` comments with no owner, ticket, or trigger condition. Redundant pre-conditions (`if (!x) throw` immediately after a Zod parse). Log lines added "for debugging" that survive into the PR. Default `else { return undefined; }` after already-exhaustive branching. `_unused` parameter prefixes that should just be deletions.
+- **Speculative generality.** A helper called once that wraps two trivial lines. A `Map` / `Set` / config object keyed by a single hardcoded value. A "strategy" / "registry" pattern with one strategy. Type unions whose only second case is `never`, a placeholder, or a string literal nobody emits.
+- **Unused parameters / overloads / fields.** Function args destructured but never read; interface methods with empty implementations; type fields written but never consumed downstream in the diff; new optional fields with no producer or consumer.
+- **Tests that exercise the framework, not the code.** Tests that assert "the mock returns what the mock returned" via `jest.fn().mockReturnValue(x); expect(fn()).toBe(x)`. Snapshot tests with no semantic assertion. Tests that mock the unit under test. Tests with names that describe the implementation (`it("calls foo.bar"…)`) rather than the behavior.
+- **Dead AI breadcrumbs.** Variables whose only use is being logged or echoed in a debug branch; `console.log` / `console.error` calls that should have been removed before commit; commented-out alternative implementations left in the diff; "\_legacy" parameter renames where nothing actually changed about how it's read.
+- **Tone / description mismatch.** PR description / commit message claims behavior the diff doesn't have, or describes the diff in language that pattern-matches engineering writing without naming the actual change. Variable / function names that sound right but don't reflect the value's role (`data`, `result`, `processed`, `_handle`, `doStuff`).
+
+For every finding, `failure_mode` must name the _concrete cost of leaving the code in_ — e.g. "future readers waste cycles understanding a wrapper that does nothing", "the unused parameter masks the next refactor's mistake", "the `try` / `catch` silently swallows an unrelated runtime error", "the restating comment goes stale in the next change and misleads readers", "the speculative helper makes call-site search return one false hit per call". A finding without a concrete cost-of-keeping fails the moderator filter.
+
+The default `suggested_fix` shape is **delete** (empty `after`) or **simplify** (smaller `after` than `before`). Suggesting "add a justifying comment" is itself slop — do not propose it. If the right move is structural (e.g. inline the wrapper), omit `suggested_fix` and describe the move in `point`.
+
+Stay in your lane:
+
+- Do **not** raise items that the Conventions agent (D) owns (terminology, lodash, datetime / money libraries, logging context shape) — that's their turf.
+- Do **not** demand observability, tests, or error handling that **does not exist** in the diff — that's the inverse of your job. You only call out what's _present_ and unnecessary.
+- Do **not** challenge whether the PR solves the right problem — that's the Adversarial agent's (A) turf when opted in.
+- A change that's small but unnecessary is still slop. A change that's large but earns each line is not.
+
+Cap output at 8 findings. `failure_mode` required.
+
+**Round 2 expanded role — audit the other agents' findings, not just your own.** In Round 2 you receive every other agent's Round 1 findings. In addition to defending or withdrawing your own (the standard Round 2 contract), you are the AI-bias counterweight in the debate: audit every other agent's finding for the same slop patterns you scan code for. Mark each such finding `disagree` with a one-line `slop:` label in the `reasoning` field. Specifically watch for:
+
+- **Asks-for-more-defensiveness.** "Add a null check", "wrap in try / catch", "validate this input", "guard against …". If the value is already typed, already validated upstream, or already guaranteed by a preceding call inside the same scope, tag `slop: asks for defensive guard on already-narrowed value`.
+- **Hypothetical concerns.** "What if a future caller passes …", "consider the case where …", "if someone later …". If the finding cannot name a current realistic input or product flow that hits the concern, tag `slop: hypothetical future caller — no current path`.
+- **Restating-the-obvious comment requests.** "Add a JSDoc explaining what this does", "consider a comment here". If the name + signature already convey intent, tag `slop: restating-the-obvious comment request`.
+- **Abstract "extract this helper" / SOLID-aesthetic refactors.** Refactor suggestions whose `failure_mode` is shape-of-the-code rather than a concrete cost of keeping the inline version. Tag `slop: refactor with no concrete cost-of-keeping`.
+- **Observability demands without a named failure mode.** "Add a log here", "emit a metric". If the finding can't name the specific failure the telemetry would help debug, tag `slop: observability without named failure mode`.
+- **Test-coverage demands on trivially-verifiable code.** "Add a unit test for this getter / passthrough / one-line wrapper". If the code's correctness is type-evident or already exercised by a higher-level test in the same PR, tag `slop: test for trivially-verifiable code`.
+- **Domain-impossible scenarios surfaced by other agents.** Any finding that worries about a state the product cannot produce given how it actually works. Apply the same litmus question to _the finding_ that you apply to code: "what real product flow could land us here?" If none, tag `slop: defends against a state the product cannot produce`.
+
+The moderator filter weighs your slop tags heavily — see the moderator filter step on AntiSlop tags. The original author gets a chance to defend in their own Round 2 entry (a concrete `final_failure_mode` naming a real, product-specific cost); without that defense, the finding is dropped.
+
+Even when your Round 1 findings are sparse because the diff is genuinely clean, do not under-spend on the Round 2 audit. The audit is often the bigger lever — it stops slop _suggestions_ from polluting the final review.
+
+#### Conditional agents
+
+**Security (E) — API surface.** Dispatched when the diff touches auth / route / permission / serializer / contract files. Posture: _"Where could this change leak data, bypass authorization, or expand the trust boundary?"_ Specifically check:
+
+- AuthN: every new or modified endpoint has authenticated identity unless explicitly public.
+- AuthZ: per-endpoint and per-resource permission checks; cross-tenant / cross-user access.
+- Secrets in configuration — no hardcoded keys, no secrets in client bundles.
+- No self-made or client-side cryptography.
+- SQL / NoSQL injection vectors (string-concatenated queries, unvalidated `$where`, raw aggregation pipelines from user input).
+- Sensitive data in response payloads — over-fetching, over-serialization, internal IDs leaked.
+- PII handling — PII fields logged, cached, or sent to telemetry.
+- Input validation at the boundary (Zod / class-validator) on every new endpoint.
+
+Cap output at 8 findings. `failure_mode` required.
+
+**Database (F) — Schema, queries, migrations.** Dispatched when the diff touches migrations / SQL / schema / model / query files. Posture: _"What breaks at production scale or during deploy?"_ Specifically check:
+
+- Index coverage for new query patterns; missing compound indexes.
+- N+1 query shapes; loops issuing per-iteration queries.
+- Schema normalization — denormalization that creates write-amplification or update anomalies.
+- Data types — range, precision, locale (numeric, date, money).
+- Cascade-delete and FK-on-delete semantics; orphan risk.
+- Migration rollback strategy; can the migration run online without downtime?
+- Backward compatibility during a rolling deploy (old code reads new schema, new code reads old schema).
+- ETL / downstream consumer impact when schema or field semantics change.
+- New collections / tables ship with the indexes their query patterns need on day one.
+
+Cap output at 8 findings. `failure_mode` required.
+
+**Frontend (G) — Conventions & UX-correctness.** Dispatched when the diff touches `*.tsx` / `*.jsx` / FE component / hook / page paths. Posture: _"Does this follow our FE conventions, and will it behave correctly under realistic user conditions?"_ Specifically check:
+
+- API calls go through v2 / custom hooks, not raw `fetch` / `axios` in components.
+- React Query: thin wrappers (`useGetQuery`, etc.), not raw `useQuery` / `useMutation`.
+- Falsy-value checks use `isDefined()` / `isNil()`, not `!value`.
+- Test actions wrapped in `act()`.
+- Zod schemas: `z.nativeEnum` used where a TS enum already exists.
+- Prop drilling — when a value is passed through ≥2 layers, is a context preferable?
+- Feature flags via `useCbhFlag` (or repo equivalent), not direct config reads.
+- New components / styles pulled from the design-system library, not built from scratch.
+- Loading / empty / error states present for any new data-fetching surface.
+- Accessibility: keyboard navigation, ARIA roles, labels on interactive controls.
+
+Cap output at 8 findings. `failure_mode` required.
+
+### Round 2 — debate
+
+Dispatch the **same set of agents** that ran in Round 1, in parallel. Each agent receives **all Round 1 outputs** (passed inline) and must:
+
+- Re-examine each of their own comments and **withdraw** any that don't survive scrutiny.
+- For each comment from the other agents: mark `agree`, `disagree` (with reasoning), or `refine` (propose a tighter version).
+- Flag items where disagreement is substantive and unlikely to resolve.
+
+Output per item: `id`, `original_author` (agent **name**, e.g. `Engineering`, `Minimalist`, `Conventions`, `AntiSlop`, `Security`, `Database`, `Frontend`, `Adversarial` — not the bare letter), `verdict` (keep | withdraw | agree | disagree | refine), `final_severity`, `final_title`, `final_failure_mode`, `reasoning`, `suggested_fix`, and rebuttals `[{from, stance, reasoning}]` where `from` is also the agent name.
+
+**AntiSlop (H) plays an enhanced Round 2 role.** Beyond defending / withdrawing its own findings and voting on the others, AntiSlop audits every other agent's findings for AI-bias patterns — asks-for-more-defensiveness, hypothetical "future caller" concerns, restating-the-obvious comment requests, abstract "extract this helper" refactors, observability / test-coverage demands without a named failure mode, and guards-against-states-the-product-cannot-produce. AntiSlop tags those `disagree` with a one-line `slop:` label in `reasoning`. These tags feed the moderator filter (see step 2 there); the original author's Round 2 entry is their chance to rebut with a concrete, product-specific `final_failure_mode`. When other agents see an AntiSlop slop tag on one of their own findings, they should either rebut with a concrete failure mode or withdraw — not both stand on the original framing and re-assert the same wording.
+
+**This is the last round.** Residual disagreement goes to the Disagreements section.
+
+## Moderator filter (main agent — runs after Round 2, before synthesis)
+
+Apply these filters in order. They are non-negotiable:
+
+1. **Drop findings with empty or hypothetical `failure_mode`.** "A future caller might…", "in case someone…" → drop.
+2. **Apply AntiSlop slop tags.** For every Round 2 entry where AntiSlop voted `disagree` with a `slop:` label in `reasoning`, check the original author's Round 2 rebuttal. If the author did not provide a concrete, product-specific `final_failure_mode` (a real user-, oncall-, or maintainer-visible cost realized through an actual product flow) that addresses AntiSlop's specific tag, **drop the finding**. AntiSlop's audit is not a unilateral veto, but the burden of proof shifts to the original author once AntiSlop tags slop. Record dropped findings in Withdrawn with the slop label so the user can audit AntiSlop's calls (e.g. `B4 — dropped: AntiSlop tagged "slop: asks for defensive guard on already-narrowed value", Engineering did not rebut with concrete failure_mode`).
+3. **Drop do-not-raise items** that slipped through.
+4. **Apply the NIT gate**. NITs that don't meet (a)/(b)/(c) → drop. NITs that do meet are kept internally but hidden by default in synthesis.
+5. **Merge near-duplicates** across agents into one item (preserve all attributions in `Raised by:`).
+6. **Apply hard caps**: at most **6 actionable** items (CRITICAL/MAJOR/MINOR) and **8 NITs** retained internally. Anything beyond is summarized as "N additional items omitted; ask for the full list."
+
+Filtered items go into Withdrawn (one-liner) so nothing is invisible.
+
+## Synthesize (main agent)
+
+### Summary
+
+One short paragraph: what the change does and your overall recommendation (ship / ship with changes / do not ship). Do not state the mode, name which agents ran, attribute headline verdicts to specific agents, or note whether Adversarial ran — that methodology metadata is noise for the user. Keep it to substance: the headline concerns and the recommendation.
+
+### Actionable
+
+Up to 6 items that survived scrutiny and the moderator filter. Format each:
+
+- **[SEVERITY] Title** — `file:lines`
+- **Point:** one sentence.
+- **Why it matters:** the `failure_mode` sentence.
+- **Counterpoint (if any):** one sentence on the rebuttal and why it didn't overturn.
+- **Suggested fix (before → after):** two stacked fenced code blocks with language tags — first labeled `// Before` (the current code from `file:lines`), then `// After` (the replacement). Use the same language tag for both. Omit when the fix is structural (no clean drop-in) and explain in prose instead. For a pure deletion, show the `Before` block and write "_Delete these lines._" under it. For a pure addition, show only the `After` block prefixed with `// Add after line <N>`.
+- **Raised by:** comma-separated agent **names** (e.g. `Engineering, Conventions`); **agreed by:** comma-separated agent names. Do not use bare letters in this field — the user shouldn't have to decode A/B/C.
+
+Render template:
+
+````markdown
+**Suggested fix (before → after):**
+
+```ts
+// Before — src/foo/bar.ts:42-45
+const x = doThing();
+if (x !== null) {
+  return x;
+}
+```
+
+```ts
+// After
+const x = doThing();
+return isDefined(x) ? x : undefined;
+```
+````
+
+Order by severity (CRITICAL → MAJOR → MINOR), then by file.
+
+### Disagreements
+
+Items where agents substantively disagreed and did not converge. One sentence per side (attribute each by agent **name**, e.g. "Engineering: …" / "Minimalist: …"), then the moderator's call with a one-line reason.
+
+### Nits
+
+Do **not** print the nits list by default. Print only one line: _"N nits available (M from convention audit). Reply `show nits` to see them."_ If N is 0, omit the section entirely. When the user replies `show nits`, print the gated NITs as one-liners with `file:lines`, the raising agent's **name**, and `[CONVENTION]` tag where applicable, then re-prompt user gate 1.
+
+### Withdrawn
+
+Terse one-liners of Round 1 comments that were withdrawn or filtered. Each line ends with the raising agent's **name** in parentheses (e.g. "C7 — superseded by C4 (Minimalist)"). For transparency only.
+
+## User gate 1 — select items
+
+Ask exactly: _"Which items do you want to act on? Reply with ids (e.g. `B1, C2`), `all actionable`, `show nits`, or `none`."_ Do not proceed until the user answers. `none` ends the skill cleanly. `show nits` prints the hidden list, then re-asks the same question.
+
+## Branch on mode
+
+### Author mode
+
+**Plan.** For the selected ids only, produce an ordered implementation plan: steps, files touched per step, tests to add/update, verification commands. Do **not** edit any files yet.
+
+**User gate 2 (author mode).** Ask: _"What do you want to do? (`implement-locally` / `post-as-review` / `both` / `edit-plan` / `cancel`)"_
+
+- `implement-locally` → execute (see below).
+- `post-as-review` → post anchored review (see below); skill ends.
+- `both` → post the review first, then execute.
+- `edit-plan` → revise from feedback, re-prompt.
+- `cancel` → stop.
+
+**Execute.** Use `TaskCreate` to track each step, apply the plan, run the verification, report results. If a step surfaces a new substantive issue not in the selected items, stop and ask before expanding scope.
+
+### Reviewer mode
+
+Skip the plan step entirely — you are not implementing someone else's code.
+
+**User gate 2 (reviewer mode).** Ask: _"Post these on the PR? (`post` / `edit` / `cancel`)"_
+
+- `post` → post anchored review (see below).
+- `edit` → ask which items to drop or refine, then re-prompt.
+- `cancel` → stop.
+
+## Posting an anchored PR review (both modes)
+
+When the user approves items to post, submit a **single** review via the GitHub Reviews API (`event: COMMENT` — never `APPROVE`/`REQUEST_CHANGES`), with every selected actionable item as an inline comment anchored to its diff line. Never use loose issue comments.
+
+Follow [references/posting-pr-review.md](references/posting-pr-review.md) exactly — it has the `gh api` call, the payload shape, the three-block review body (attribution line, synthesis summary, apply-all prompt), and the per-comment body budget and format. After posting, print the review `html_url` and a one-line summary of how many comments were posted (and how many fell back to general notes, if any).
+
+## Rules
+
+- Use fresh `general-purpose` subagents for every round — do not reuse other subagent types.
+- Issue all agent calls in a single message for each round so they run truly in parallel.
+- Keep large content on disk (`/tmp/in-depth-review-*`) so round-2 prompts stay compact.
+- If one agent fails or returns malformed output, re-dispatch **that agent only**; do not restart the round.
+- If the diff is empty, stop with a one-line message — do not invent findings.
+- Do not auto-apply recommendations and do not auto-post reviews. Both user gates are mandatory.
+- The moderator filter is non-negotiable: empty `failure_mode` → drop, NIT not meeting the gate → drop, do-not-raise items → drop, caps applied.
+- Hide nits by default. Only print them when the user replies `show nits`.
+- Reviews are always `event: COMMENT`. Never approve or request changes on the user's behalf.
+- Posted comment bodies are terse: ≤60 words of prose + the code block, no bulleted lists, no prose preamble on the `suggestion`, no trailing addenda, and `Why it matters` is dropped when it would only rephrase the Point. The Example/context block is opt-out — include it only when prose + `suggestion` is genuinely ambiguous.
+- Conditional agents (E/F/G) run only when classification matches. Do not invent triggers; if the user wants a forced full run, they will say so.
+- The Adversarial agent (A) is opt-in. Default selected set is Engineering / Minimalist / Conventions / AntiSlop (B/C/D/H), plus the classified subset of Security / Database / Frontend (E/F/G). Dispatch Adversarial only when the user explicitly asks (`with adversarial`, `with agent a`, `+A`, etc.). Surface the Adversarial on/off decision in the Summary so the user can see what ran.
+- **Refer to agents by name in every user-facing surface** — Summary, Actionable items (`Raised by` / `agreed by`), Disagreements, Withdrawn, and `original_author` / `rebuttals[].from` in Round 2 output. Bare letters (A/B/C/D/E/F/G) are acceptable only as ID prefixes (`B1`, `C3`) and as parenthetical shorthand next to the name. The agent-name table in the "Agent roster" section is the authoritative mapping; do not invent alternative names.
+- Freshness preflight is mandatory before any agent dispatch. Subagents read repo context via `git show "<context_ref>:<path>"` / `git grep ... "<context_ref>"`, not the worktree filesystem, unless the resolved `context_ref` is `worktree (stale, user accepted risk)`.
+- Never run state-modifying git commands on the user's behalf (`checkout`, `stash`, `reset`, `clean`, `pull` with merge). The skill warns and asks; the user resolves local state. `git fetch` is allowed because it does not modify the working tree.
+- Cross-repo evidence is opt-in by the user. Subagents tag findings with `evidence_required` and cap them at MAJOR until verified; the moderator asks the user for paths or `gh:owner/repo` slugs and runs the freshness preflight on each before treating the evidence as load-bearing. `skip` downgrades the finding to MINOR with a "speculative" prefix.
+- `suggested_fix` is always a `{ before, after }` object of language-matched code snippets (never prose). **In-chat synthesis Actionable section:** render both halves as separate language-tagged fenced blocks (`// Before` then `// After`) — the user has no GitHub renderer in their terminal, so they need the pair to review the change before approving the post. **PR-review inline comments:** render ONLY the `suggestion` block — GitHub already renders the diff vs. the anchored line(s), so a separate `// Before` block would duplicate what's on screen. Empty `before` means pure addition (still emit a `suggestion` block; prefix `after` with `// Add after line <N>`). Empty `after` means pure deletion (omit the `suggestion` block and write "_Delete the anchored line(s)._"). Omit `suggested_fix` entirely for structural changes with no clean drop-in.