---
name: staff-engineer-code-review
description: "Reviews a change like a staff engineer: finds the bugs that pass CI yet fail in production, and blocks only on findings that deserve it. Use when an engineer needs a pre-merge review that looks for production failures such as races, missing timeouts, and unsafe migrations that pass the test suite. Do not use for style linting or reviewing a design before code exists. Related topics: coding, technical."
---

# Staff Engineer Code Review

Reviews a change like a staff engineer: finds the bugs that pass CI yet fail in production, and blocks only on findings that deserve it.

## When to use

Use this skill when an engineer needs a pre-merge review that looks for production failures such as races, missing timeouts, and unsafe migrations that pass the test suite. Do not use it for style linting or reviewing a design before code exists.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Read the change for its intent and compare it against the stated behaviour.
3. Search for production failure patterns including races, unbounded queries, duplicate retries, and missing timeouts.
4. Describe each finding with file, line, impact, a realistic trigger, and a fix.
5. Label a finding Blocking only when it risks data loss, outage, security exposure, or wrong results.
6. Give a verdict with the count of blocking findings.

## Inputs

- **The diff or files** (longer free text)
- **What the change is meant to do** (longer free text)
- **System context** (longer free text)
- **Language and framework** (free text, e.g. "Node and Express")
- **Risk level** (choose one: Low, Medium, High, Critical path)
- **Review strictness** (choose one: Lenient, Balanced, Strict)

## Output

A findings list with file and line, impact, trigger, fix, and a Blocking, Suggestion, or Nit label, then a verdict and the blocking count.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Staff Engineer Code Review

Review this change for problems that tests will not catch.

- The diff or files: {{The diff or files}}
- What the change is meant to do: {{What the change is meant to do}}
- System context: {{System context}}
- Language and framework: {{Language and framework}}
- Risk level: {{Risk level}}
- Review strictness: {{Review strictness}}

Read for intent first, then hunt for production failures: race conditions, missing transactions, unbounded queries, N+1 access, retries that duplicate work, timeouts absent on network calls, unhandled null or empty cases, error paths that swallow failures, migrations that lock tables, and secrets or personal data in logs. For each finding give the file and line, what breaks, a realistic trigger, and a suggested fix. Label each finding Blocking only when it can cause data loss, outage, security exposure, or wrong results; label everything else Suggestion or Nit. Do not block on style. End with a verdict of Approve, Approve with suggestions, or Request changes, and count the blocking items.

## Pitfalls

- Marking style preferences as Blocking, which trains authors to ignore the label.
- Reporting a bug with no trigger, so the author cannot judge how likely it is.
- Reading only the diff and missing that a changed function has callers elsewhere.