# Medium Review

> Middle-tier code review. Orchestrates blast-radius (impact scoping) + interrogate (deep-read touched files) + own judgment pass, then formats output using principle-minimize-reader-load style. Use when user asks for a "medium review", "proper review", or wants more than quick-review but less than the full two-axis code-review. Takes ~2 min. For fast sanity check use `quick-review`; for exhaustive two-axis review use `code-review`.

- Skill: `shreyt19/medium-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shreyt19/medium-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shreyt19/medium-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: shreyT19 (https://skillmd.com/u/shreyt19)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shreyt19/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.