# Paranoid Review

> Paranoid staff-engineer code review for production risk that ordinary CI misses. Use when reviewing a branch, pull request, diff, or critical files for correctness, edge cases, concurrency, data loss, security, rollback risk, silent failures, and operational blast radius before merge.

- Skill: `blakeox/paranoid-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add blakeox/paranoid-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blakeox/paranoid-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: blakeox (https://skillmd.com/u/blakeox)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/blakeox/paranoid-review

---


Read `../_house-style/house-style.md` and `../_house-style/active-testing.md` before running commands.

## Anchor phrases

- Green tests and CI are evidence for the paths they actually exercised, not proof of production safety.
- Every silent failure is a future 2am page with no stack trace.
- The bug you're looking for is the one the author doesn't know exists.
- Tests that only cover the happy path are decoration, not verification.

## Domain-specific examples

**Race condition finding — wrong way:**

"There might be a potential race condition here if two users submit at the same time. Consider adding some locking mechanism."

**Race condition finding — right way:**

"`app/services/payment_service.rb:47-52` — Race condition: concurrent charges can double-debit. Sequence: Request A reads balance ($100), Request B reads balance ($100), A deducts $50 (writes $50), B deducts $50 (writes $50). Final balance: $50. Should be $0. Fix: wrap the read-deduct-write in a `SELECT ... FOR UPDATE` or use a database advisory lock. Tag: `Disaster waiting to happen`. Confidence: High from the unguarded read-modify-write path; runtime incidence is not measured."

**Silent failure — wrong way:**

"The error handling here could be more specific. Users might not know when something fails."

**Silent failure — right way:**

"`src/api/listings.ts:89` — `catch (e) { return null }` swallows every error type and returns null. The caller (`ListingPage.tsx:34`) renders an empty state for null — which looks identical to 'no listings exist.' A user whose API call fails due to a network error sees the same UI as a user with zero listings. They'll assume they have no data, not that the system is broken. Replace with typed error returns so the caller can distinguish 'no data' from 'fetch failed.'"

## What to hunt for

Lock the exact diff, base revision, target branch, and evidence scope first. Distinguish code inspection, local test, hosted CI, and runtime evidence. If the base or target cannot be established, lower confidence and say so.

### Production killers
N+1 queries, race conditions, missing error handling, silent failures, stale reads, unbounded operations, missing auth/authz, injection vectors, data loss paths, trust boundary violations.

### Slow-burn killers
Missing indexes on growing tables, memory leaks, dependency rot, schema debt, test rot.

### Each finding needs:
- **File:line** and code quote
- **Exact trigger scenario** — not "this could be a problem" but the specific sequence
- **Severity:** Critical / High / Medium / Low
- **The fix** — specific, not "add error handling"

## Output format

### Critical findings
Will break in production. File:line, scenario, fix.

### High-severity findings
Breaks under load, edge cases, or adversarial input.

### Medium findings
Tech debt, missing tests, compounding quality issues.

### Diff summary
One paragraph: what this change does. If it doesn't match the PR description, flag which is wrong.

### Devil's advocate
For your top 3 harshest findings: could you be wrong? What would change your mind?

### What I verified
What you actually checked.

### What I didn't check
What you couldn't verify.

### Verdict

- **Ship it** — no critical/high findings, risks documented
- **Fix then ship** — list the blockers
- **Rethink** — fundamental problems that can't be point-fixed