Medium Review

Medium review

Middle tier between quick-review (30s glance) and code-review (5+ min two-subagent audit).

Orchestrator — invokes other skills.

When to use

• "medium review", "proper review", "review this properly but keep it tight"
• Small-to-medium PR where quick-review is too shallow but full code-review is overkill
• Changes touching 2-8 files, non-trivial logic, no formal spec

When NOT to use

• Trivial WIP diff → quick-review
• Full PR against merge target with a spec → code-review (two-axis)
• Architectural refactor across many files → code-review

Process

1. Read the diff

• Get: git diff <ref>...HEAD (ask for ref if user didn't name one; default to main)
• Get: git log <ref>..HEAD --oneline for commit context
• Note changed files. Empty diff → stop.

2. Invoke blast-radius

Delegate impact-scoping to blast-radius skill.

Ask it: "For the diff <ref>...HEAD covering files [list], what else in this repo touches the same symbols / files / interfaces? What breaks if these changes ship?"

Capture its output. Do not re-derive.

3. Invoke interrogate on touched files

Delegate deep-reading to interrogate skill.

Ask it: "For files [list from step 1], explain what each does, its dependencies, its call sites, and any subtle behavior a reviewer should know before judging changes here. Focus on the changed regions."

Capture its output.

4. Own judgment pass

Now you have: diff + impact map (from blast-radius) + code understanding (from interrogate). Do the actual review:

• Correctness — does the change do what the commit messages / PR title claim?
• Impact fit — do the blast-radius findings show any caller / consumer this diff forgot to update?
• Local sanity — inside the touched functions, does the logic hold? Any obvious bugs, edge cases, off-by-ones?
• Fit with existing code — does the change follow patterns interrogate surfaced? Any glaring inconsistency?

Do NOT do:

• Full Standards + Spec axes — that's code-review (advanced)
• Historical rationale investigation — that's why
• Running tests — that's principle-prove-it-works

5. Format output via principle-minimize-reader-load

Apply principle-minimize-reader-load conventions to the writeup: no filler, no headings for tiny reviews, one finding per line, verb-first.

Fixed sections (drop any that would be empty):

• Change summary — 1-3 lines: what the diff does
• Impact (from blast-radius) — bulleted; who else is affected + not updated
• Findings — bulleted, one line each. Format: <file>:<line> — <problem> — <suggested fix>. Rank most-serious first.
• Not reviewed — one line if anything was skipped (huge file, binary, generated code).

Output style

• Under one screen for reviews of ≤ 8 files. Bigger diffs → summary + link to per-file sections.
• No praise. No disclaimers. No "overall the code looks good" filler.
• Apply unslop if writing more than a few lines.

Escalation

If mid-review you realize the change is architecturally significant or has a formal spec you can pull → recommend user re-run with code-review instead. Say so explicitly, do not silently upgrade.