| type | Phoenix Skill |
| name | phoenix-review |
| description | Review completed work against the Intent Contract's acceptance criteria using objective evidence, not opinion — re-run every check, confirm no regressions, inspect the tamper-evident trace, and surface only real issues (bugs, unmet criteria, regressions). Use before shipping, after a feature is built, or when the user says /phoenix-review or "review this". |
| license | MIT |
phoenix-review — evidence-based review, not vibes
Overview
Before anything ships, prove it meets the intent — objectively. A Phoenix review is not a re-read of
the diff hoping to spot problems; it re-runs the checks, confirms nothing else regressed, and inspects
the trace to confirm the green you see is real and was reached honestly. It surfaces correctness
issues only — the model already handles style; Phoenix reviews whether the work actually works.
When to use
- A feature/step set is "done" and headed for
phoenix-ship.
- Before merging or handing off.
- After a non-trivial
phoenix-build or phoenix-debug session.
The review gate
Completed work
│
▼
1. Re-run the ACCEPTANCE check (from phoenix-think) → must be green
│
▼
2. Re-run the FULL suite/build/lint → no regressions
│
▼
3. phoenix_verify_trace → chain intact, real green→work→green
│
▼
4. Surface ONLY real issues (bugs / unmet criteria / regressions)
│
▼
green evidence ─► phoenix-ship any red / broken trace ─► phoenix-debug
1. Re-run the acceptance gate
phoenix_sense(acceptance_check) from the Intent Contract. If it isn't green, the work is not
review-passed — full stop. Send it back to phoenix-build/phoenix-debug.
2. Check for regressions
Sense the full suite/build/lint, not just the new test. The most common review miss is a change
that satisfies its own check while breaking something adjacent. Use phoenix-context impact to
confirm you tested everything in the blast radius.
3. Inspect the trace
phoenix_verify_trace must report ok:true with an intact hash chain showing a genuine
green→(work)→green path. A broken chain, or a "green" with no prior red, means the gate was skipped or
the evidence was edited — treat that as a failed review.
4. Surface only what matters
Raise: unmet acceptance criteria, bugs, regressions, security/correctness risks, missing error handling
on a real failure path. Do not raise style, naming taste, or formatting nits — that's noise, and
the model handles it already. High signal-to-noise is the whole value of the review.
Common Rationalizations
| Rationalization | Reality |
|---|
| "The new test passes, so it's good." | The new test passing says nothing about the 200 other tests your change might have broken. Run the full suite. |
| "I read the diff, it looks fine." | Reading a diff is self-grading. Re-run the checks; evidence, not eyeballs, gates a review. |
| "The trace is probably fine, skip it." | The trace is how you know the green wasn't faked or the gate skipped. Verify it — it's one call. |
| "I'll note these style nits too." | Style nits drown the real issues. Review correctness; let the model handle taste. |
Red Flags
- Acceptance check not re-run. → Re-run it; that's the whole gate.
- Only the new test was run. → Run the full suite for regressions.
- Trace shows green with no preceding red. → The gate was skipped; the evidence is suspect.
- The review is mostly style comments. → Refocus on correctness; cut the nits.
Next
Green evidence → phoenix-ship. Any red, regression, or broken trace → phoenix-debug.
