Reasoning reflexion

Reflexion (Self-Critique + Correction)

What this is — and isn't

Reflexion is a two-pass discipline: (1) critique — reread your own draft as an adversary looking for what's wrong, not for what's right; (2) correct — fix only the issues the critique surfaced, then stop.

It does not raise the model's ceiling. It re-spends compute the model already has on a task — finding errors — that competes with the task of generating the draft in the first place. A single unbroken generation pass has to handle content and correctness at once; splitting it into two passes gives correctness a full, undivided turn. This reliably catches: skipped edge cases, constraints from the prompt that got silently dropped, off-by-one/arithmetic slips, unsupported claims stated as fact, internal contradictions, and format/schema violations.

It will NOT catch errors that require knowledge or reasoning the model doesn't have — if it didn't know a fact was wrong while writing it, it usually won't know while reading it either. It also can't rescue a wrong approach chosen from the start; that needs re-planning (see reasoning-plan-then-execute), not critique. Treat reflexion as a net for slips, not a substitute for a verifier with an independent source of truth (see reasoning-verifier-loop for that).

Inputs required

1. The task/spec the draft was supposed to satisfy — instructions, constraints, acceptance criteria. Without this, "critique" has nothing to check against and degrades into vague politeness.
2. The draft itself, verbatim — the exact output to be critiqued.
3. (optional, recommended) A checklist of failure modes specific to the task type — e.g. for code: null handling, off-by-one, resource leaks; for extraction: missing fields, wrong types, hallucinated values; for analysis: unstated assumptions, cherry-picked evidence, numbers that don't reconcile.

Steps

1. Freeze the draft. Do not edit yet — treat it as read-only input to step 2.
2. Critique pass — find, don't fix. Reread the draft against the task spec and the failure-mode checklist, in the voice of a skeptical reviewer who assumes a defect exists and is trying to locate it. Produce a list of concrete issues, each with: what's wrong, where (line/section/field), why (which spec requirement or logical check it fails), severity (blocking vs. cosmetic). If nothing survives honest scrutiny, say so explicitly — never invent an issue just to look thorough.
3. Correction pass. Using only the issue list from step 2, rewrite the draft to resolve each item. Do not perform an unrelated fresh rewrite — every change should trace back to a specific critique item, so the diff stays reviewable.
4. Re-check the fix, once. Confirm each critique item is actually resolved in the corrected draft, not just acknowledged. If a fix introduced a new issue, note it — but don't loop indefinitely.
5. Stop after 2 rounds max. One critique-then-correct cycle is enough for most drafts; run a second only if round 1 found blocking issues. If round 2 still finds blocking issues, escalate (bigger model, human review, or re-plan) instead of running a third round — reflexion converges fast or it doesn't converge at all.

Guardrails

• Hard cap: 2 rounds. A third round on the same draft usually signals a structural problem (wrong approach), not a slip — stop and re-plan instead of iterating further.
• The critique pass must be allowed to output "no issues found." A critic that always finds something isn't critiquing, it's padding — that destroys the signal.
• Keep critique and correction as two distinct, visible passes. Don't silently merge them into one rewrite — the separation is what makes this different from just "try again."

Output format

## Critique
1. [blocking|minor] <issue> — <where> — <why: which requirement/check it violates>
2. ...
(or: "No issues found against the spec.")

## Corrected draft
<full corrected output>

## Resolved?
- Issue 1: fixed / not applicable / carried to round 2 (reason)
- Issue 2: ...

Worked example

Task: "Write a function days_between(d1, d2) that returns the number of whole days between two ISO date strings, always non-negative."

Draft (input to reflexion):

from datetime import date

def days_between(d1, d2):
    a = date.fromisoformat(d1)
    b = date.fromisoformat(d2)
    return (b - a).days

Critique pass:

1. [blocking] Return value can be negative when d1 is later than d2 — violates "always non-negative." Fix: wrap the result in abs().
2. [minor] No explicit handling for malformed input strings; date.fromisoformat raises ValueError on bad input, which is acceptable but undocumented — not blocking.
3. The day-subtraction logic itself is correct and the signature matches the spec — no issue there.

Correction pass:

from datetime import date

def days_between(d1, d2):
    """Return the number of whole days between two ISO date strings (always non-negative)."""
    a = date.fromisoformat(d1)
    b = date.fromisoformat(d2)
    return abs((b - a).days)

Resolved?

• Issue 1: fixed (abs() added).
• Issue 2: not applicable — left as documented raise behavior via the docstring; no code change needed.

---

See also: reasoning-plan-then-execute (fixes a wrong approach, which critique alone cannot), reasoning-verifier-loop (adversarial check against an independent standard, not just a reread), reasoning-self-consistency (for tasks with one correct answer, sampling+voting is often cheaper than critique).