Adversarial Self Critique

让模型以「你没写过这份东西」的敌意首席专家身份冷审自己的产出：默认一定有问题，且每条发现都必须给出具体位置与失败方式。

模型会把自己的产出当作「意图」而非「文本」来读，因此自审默认变成自夸。本提示词用角色隔离与「先假定有问题」打破这一点，并要求结构化的发现——没有具体位置与失败方式的就不算发现。文中还加入事前验尸提问和「世界级会怎么做」提问，用以发现「缺了什么」而不只是「哪里错了」，并提供三评审者变体：只保留至少两个视角都在意的发现。

# Self Critique

**Use when:** you have an artefact and you want the real flaws found before you ship it.
**Works with:** any model. Strongest when run in a fresh context.
**Pairs with:** [loop_engineering.md](loop_engineering.md), [rubric_scoring.md](rubric_scoring.md)

A model reviewing its own work is generous by default. It reads its own output as intent rather than as text. This prompt breaks that.

---

## The prompt

```text
ADVERSARIAL REVIEW

You did not write this. You are reviewing it cold.

Your role: a principal level specialist in this exact domain who has been
asked whether this is good enough to ship. You have seen a hundred of
these. You have a reputation for catching what everyone else missed. If
this ships with a flaw you failed to catch, that is on you.

Assume there are problems. There always are. Your job is to find them,
not to decide whether the work is broadly acceptable.

FIND FAULTS
For each fault, give exactly this:
  Severity: Blocker | Major | Minor | Polish
  Location: file and line, or section, or element. Be exact.
  Failure: the concrete bad outcome. Who hits it and what happens.
  Fix: the specific change. Not "improve error handling".
  Confidence: certain | likely | worth checking

SEVERITY MEANS
  Blocker: wrong output, data loss, crash, security hole, or it does not
           meet the stated requirement.
  Major:   works today but will break, confuse users, or cost real time
           to live with.
  Minor:   real but small. Would be a comment in review, not a rejection.
  Polish:  taste and consistency.

RULES
- No fabricated faults. A quota is not a goal. An invented fault is worse
  than a missed one because it wastes a fix.
- No vague faults. "Could be more robust" is not a fault. Name the input
  that breaks it.
- Evidence over memory. If the claim is about behaviour, say how you
  checked. If you did not check, mark it "worth checking".
- Ranked output. Blockers first. Do not bury the important one.
- If you genuinely find nothing at a severity level, do not stay silent.
  Walk the checklist below out loud and say why each item passes.

THEN, SEPARATELY
1. What is the single weakest part of this work?
2. What did the author probably not think about at all?
3. If this fails in production in six months, what is the most likely
   cause? Answer as if it already happened.
4. What would the world class version of this do that this does not?

END WITH
A one line verdict: ship, ship after fixing the blockers, or rework.
```

---

## Lens checklist

Give the reviewer the lenses that match your artefact. Running lenses one at a time finds more than running them together.

**Code**
- Correctness on the happy path
- Empty, null, zero, one, and maximum inputs
- Concurrency and ordering
- Error paths and what the user sees when they fire
- Resource cleanup and leaks
- Security: input trust, secrets, permissions, injection
- Performance under real data sizes, not toy ones
- Readability for someone who joins next month
- Tests: do they fail if the code is wrong

**Design and UI**
- Visual hierarchy: is the most important thing the most prominent
- Spacing rhythm and alignment against a real grid
- Every state: default, hover, pressed, focus, disabled, loading, empty, error, success
- Contrast and text size against accessibility minimums
- Motion: duration, easing, and what it communicates
- Behaviour at the smallest and largest supported size
- Does it look like the platform, or like a web page pasted onto it

**Writing**
- Does the first sentence carry the point
- Any sentence that could be cut without loss
- Claims without support
- Jargon that a target reader would not know
- Structure: would a skimmer get the point

---

## Running it cold

The review gets noticeably harder when the model cannot see itself as the author.

- **Fresh chat:** paste only the artefact and the review prompt. No history.
- **Subagent:** in Claude Code, spawn a reviewer subagent and give it the artefact plus the rubric only, not your reasoning.
- **Different model:** have one model write and another review. Different training, different blind spots.

If none of those are available, at least put the review in a new message and open with "You did not write this."

---

## Multiple reviewers

For high stakes work, run three reviewers with different priorities and keep what two of them agree on.

```text
Review this three times, as three different people:
1. A correctness obsessive who only cares whether it does the right thing
   in every case.
2. A maintainer who will own this code for two years and cares about what
   it will cost to live with.
3. A user who has never seen this before and is trying to get something
   done.
Keep the three reviews separate. Then list only the findings that at least
two of them would care about, ranked.
```

This filters out noise. A finding that only one lens raises is usually taste. A finding that two raise is usually real.

---

## Why it works

- **Role separation** removes the author's bias. The model is not defending anything.
- **Assumed guilt** flips the default. The question stops being "is this okay" and becomes "where is the problem".
- **Required structure** stops vague praise. A finding without a location and a failure is not a finding.
- **The pre mortem question** reaches problems that a checklist misses, because it asks the model to imagine an outcome and work backwards.
- **The "what would world class do" question** catches missing work, not just wrong work. Checklists find bugs. That question finds absence.