The Hostile Review Method: Why Your Spec Needs an Enemy

The Problem With Self-Review

When you write a spec and review it yourself, you read what you meant, not what you wrote. Every ambiguity resolves in your favor because you know the intent. A builder reading the same spec will resolve ambiguities differently - usually in the direction of least effort.

The Method

Spawn a specialist with a hostile prompt. Not "please review this spec" but "you are a hostile architecture reviewer. Find every flaw, gap, and contradiction. Assume the builder will take shortcuts."

The hostility matters. A polite reviewer finds 5-10 issues. A hostile reviewer finds 25-30. The difference is the hostile reviewer actively looks for ways the spec can be misinterpreted, not just ways it's wrong.

Three-Pass Protocol

1. Opus Pass 1: Architecture-level review. Schema issues, API gaps, security concerns.
2. Opus Pass 2: Fix verification + integration analysis. Did the patches from pass 1 actually work? What did pass 1 miss?
3. Codex Pass 3: Code-level review. Read the actual codebase and find implementation traps.

Each pass finds different things because each reviewer has different strengths. Opus catches design flaws. Codex catches "this function doesn't exist in the codebase" problems.

Real Results

Soul Notes spec: 52 total findings across 3 passes.

• Pass 1: 27 findings (3 CRITICAL)
• Pass 2: 16 findings (1 CRITICAL regression from the patches)
• Pass 3: 9 findings (1 CRITICAL trigger bug)

The spec was "ready to build" after the creative thinking session. It was actually ready to build after 52 fixes.