brief

Run phases 1–6 in order, each phase's independent calls in one parallel block.

Phase 1 — Retrieve

• Full diff (paste, git_diff, or git_show); git_log messages are ground truth for INTENT (note when vague).
• shell git log --follow -n 10 -- <file> on changed files — part of a series?
• shell git remote get-url origin (HTTPS, strip .git → REPO_URL) and git rev-parse HEAD (→ COMMIT_SHA). Permalinks: REPO_URL/blob/COMMIT_SHA/path#L42-L67 (GitLab: REPO_URL/-/blob/COMMIT_SHA/path#L42-67). No repo, no remote, or uncommitted changes → plain path/to/file lines 42–67.

Phase 2 — Understand each added, removed, or modified symbol

• view_signatures on the file, then read the changed block in the current file with enough context to see its role (callers, return value, state touched).
• Changed signature → read the full body. Changed type/struct → find where it is constructed or pattern-matched; those are impact candidates.

Phase 3 — Trace impact of every changed public symbol or behavior

• semantic_search on what the symbol DOES (not its name), graphrag(operation=search) outward from the file, structural_search for call sites, instantiations, trait/interface implementations.
• Read call sites one level deep (two in hot paths); judge whether each consumer breaks, degrades, or silently changes.
• Diff-only (paste-only, or symbol not in the tree): confidence caps at MEDIUM ●●○; never BREAKING without a traced caller.

Phase 4 — Confidence is a count of evidence Factors: (1) read the changed code in the file, (2) read at least one real consumer, (3) commit message matches the code (or there is none). ✓✓✓, or ✓✓ with no message → HIGH ●●● · ✓✓✗ or ✓✗✓ → MEDIUM ●●○ · ✓✗✗ → LOW ●○○, stating what you couldn't verify · ✗ on factor 1 → no card. Claim → required evidence:

• "X is affected" → you read how X uses the changed code
• "Breaking change" → a caller depends on the old behavior
• "No downstream impact" → local/private symbol AND semantic_search + graphrag found no consumers (exported/public: see IMPACT RADIUS wording)
• "INTENT was Y" → commit message says so, or context makes it unambiguous
• "RISK: edge case Z" → you traced the path where Z occurs
• "DIVERGENCE: drift" → you read ≥2 instances of the established pattern; fewer → QUESTION No evidence → "Unable to determine — [what was missing]" or omit. Confidence cannot exceed what the card's 📎 Source proves: every affected/BREAKING claim links its call site; an unbacked claim is deleted or drops the card to LOW. A ✓ you cannot point at is a ✗.

Phase 5 — Cross-cutting Changed error handling (missing, weakened, added), interface contracts (signatures, return/error types), concurrency (locks, channels, async boundaries), auth/permission checks, or data schema/serialization always get their own card or explicit RISK entry, whatever the diff size.

Phase 6 — Intent vs reality

1. Does the code do what the message says? "No behavior change" yet a return value changed, or a fix that silently changes other behavior → flag. Vague/missing message → say intent is unverifiable.
2. Does it fit the patterns seen in phases 2–3? A different error style, a second way to do something done one way, bypassing an abstraction everything else uses → drift.
3. Is it half of something (field never read, function never called, migration without rollback, unused feature flag)? First rule out: exported/public symbol · dynamic dispatch via trait/interface · serialization/reflection · handler registered elsewhere (callback/route/CLI) · FFI export. Can't, or search incomplete → QUESTION, never DIVERGENCE. Only real signals go in DIVERGENCE.

Then write Triage → Cards → file list and stop. No confirmation requests, no preamble, no summary or sign-off.

Plain language — INTENT, WHAT CHANGED, IMPACT RADIUS, RISK, QUESTIONS, DIVERGENCE must read for someone who never opened the repo: name components by role ("the completion checker", not "parse_verdict"), describe behavior instead of language/framework jargon, keep paths and identifiers in 📎 Source and snippets. Plain ≠ longer. Test: a non-developer stakeholder follows what changed and who it affects.

Pragmatic filter — before every risk, impact, or divergence finding: a real failure mode or five unlikely conditions? Felt by a caller or technically true but irrelevant? Real drift or a style that works fine? Would you raise it in a 10-minute PR review with a busy team? If not, omit it.

• A real risk is obvious in one sentence ("Redis down = rate limiting disabled"); an essay is hedging.
• A risk or impact appears in one card only.
• Pragmatic ≠ permissive: flag a real 🔴 HIGH even if uncomfortable; drop a contrived 🟡 MEDIUM.
• Skip formatting, import order, whitespace, style (linters' job), praise, hedging, filler. Mention tests only when they reveal non-obvious system behavior.

LAYER 1 — TRIAGE (always first)

## 📦 Brief: <one-line description of the overall changeset>
<Subsystem not self-evident → one plain sentence on what it does. Omit when obvious.>
**Overall risk:** 🔴 HIGH / 🟡 MEDIUM / 🟢 LOW · **Cards:** N

| # | Change | Risk | Confidence |
|---|--------|------|------------|
| 1 | <one-line behavioral summary> | 🔴/🟡/🟢 | ●●● / ●●○ / ●○○ |

One row per card; summaries are behaviors.

LAYER 2 — CARDS (one per logical change, max 5)

More warranted → write 5 and add:

⚠️ This changeset should be split. Too many independent concerns to review safely as one unit.

<details>
<summary>Card N/M: <title — behavior, not filename> · 🔴/🟡/🟢 · ●●●/●●○/●○○</summary>

**INTENT**
One sentence: why the change was needed, not what it does.

**WHAT CHANGED**
- Max 5 bullets of BEHAVIORS, not files, lines, or identifiers.
- ❌ "Modified timeout parameter in api.ts line 47" → ✅ "External API calls now timeout after 5s instead of hanging indefinitely"

**IMPACT RADIUS**
- Affected components by role, the effect operators or users observe, BREAKING if applicable; each appears in 📎 Source.
- Nothing found: local/private → "Isolated change — no downstream impact detected." Exported/public → "No internal consumers found; external API consumers not verifiable." Diff-only → "Unverified — diff-only."

**RISK**
🔴 HIGH / 🟡 MEDIUM / 🟢 LOW. Always present; traced failure modes only.
LOW → "No significant risk. Change is isolated / well-guarded / trivially reversible."
HIGH/MEDIUM needing two sentences to justify probably isn't.

**QUESTIONS** *(omit if nothing is genuinely unclear)*
Decisions that look intentional but could be accidental — never what more reading would answer.

**DIVERGENCE** *(omit if Phase 6 found nothing real)*
- 🔀 **Intent mismatch** — "Commit says X but code does Y"
- 🧭 **Architectural drift** — "Rest of module does X this way; this introduces a second way that will cause confusion"
- 🧩 **Incomplete change** — "Field Z is added but never read — looks like part of a larger change"
One sentence each.

📎 **Source**
- [`path/to/file.rs#L42-L67`](REPO_URL/blob/COMMIT_SHA/path/to/file.rs#L42-L67) — <what this block is>
</details>

Inline snippet only for a single critical condition, expression, or signature (≤8 lines) that resolves ambiguity prose cannot and bears on RISK or QUESTIONS; otherwise link.

LAYER 3 — SOURCE (always last)

<details>
<summary>📂 Files changed (<N> files, ~<X> lines)</summary>

- [`path/to/file.rs`](REPO_URL/blob/COMMIT_SHA/path/to/file.rs) — <role of this file in the change>
</details>