Deep Code Review (Matthew's process)

This skill captures the review lens Matthew applies to pull requests, diffs, and repo slices. It is deliberately more thorough than a generic code review: it prioritizes issues that create real product, operational, or technical-debt impact over style nits, and it evaluates code against seven specific lenses rather than a keyword checklist.

Use it when Matthew asks for a deep review, a thorough review, or signals he wants more than a quick pass (e.g. "what will break in prod", "check the failure modes", "audit observability", "is this well tested"). If he just wants a quick security or performance check, defer to the built-in engineering:code-review instead.

Step 1 — Gather the review context

Before running the review, fill in the six context fields the prompt needs. If any are missing from the user's message, ask for them using a single AskUserQuestion call with up to four questions. Do not invent values — an unclear review target leads to unreliable findings.

The six fields:

1. Review target — the diff, list of files, PR link, or repo slice to review.
2. Scope limits — any parts of the target Matthew wants skipped.
3. Base branch / comparison point — what to diff against (e.g. main, the prior release tag, a specific commit).
4. Known exclusions or already-known findings — things already covered elsewhere that don't need to be re-surfaced.
5. Runtime evidence available — whether there are tests, logs, traces, metrics, or reproduction steps to ground claims.
6. Project maturity — where is this code in its lifecycle? (e.g. "sprint 2, pre-prod", "production, year 3", "prototype", "stabilization / pre-GA"). This calibrates severity — see Step 2.