All Skills
/to-review Phase 4: Looking Back

The /to-review Skill

Conducts an unsparing post-implementation audit across the 5 SOLID principles, boundary specialization, 14-vector defensive security, asymmetric adversarial refutation, and release readiness.

"Fourth. Examine the solution obtained. Can you check the result? Can you check the argument? Can you derive the result differently? Can you see it at a glance? Can you use the result, or the method, for some other problem?" — George Pólya, How to Solve It (1945)
MODE 1: FULL QUALITY & RELEASE AUDIT (DEFAULT) 
/to-review @docs/spec/checkout-spec.md @docs/plan/checkout-plan.md Audit code against 5 SOLID principles, mutation checks, defensive security, and issue release GO/NO-GO verdict.
MODE 2: FOCUSED ADVERSARIAL SECURITY AUDIT (/to-review security) 
/to-review security @docs/spec/checkout-spec.md Conduct focused adversarial security audit on trust boundaries, auth, tenant isolation, and LLM/MCP sinks.

What it does

to-review executes Phase 4 (Looking Back) of George Pólya's heuristic framework. It performs an uncompromising quality and security audit of completed code modifications against Robert C. Martin's 5 SOLID design principles, boundary specialization ($0, 1, \text{null}$, max payloads), and 14 comprehensive defensive security attack vectors.

It supports two dedicated operational modes:

  • Full Quality & Release Audit (Default): Complete evaluation across all 11 stages (Mutation checking, SOLID, Boundaries, 14-Vector Defensive Security, Performance benchmark ledgers, and GO | NO-GO Release Gate with Timed Rollback Plan). Required for PR merge sign-off.
  • Focused Security Audit (/to-review security): Targeted adversarial audit focusing on Trust Boundary Reconnaissance, Asymmetric Refutation, and the 14 Defensive Attack Vectors, scoping directly to trust boundaries and producing actionable findings without requiring unrelated performance benchmark ledgers.

It eliminates confirmation bias through an Asymmetric Adversarial Doubt Cycle (mandated to disprove rather than validate: "Find what will break in production") and classifies all candidate findings using a rigorous 3-State Verdict Taxonomy: CONFIRMED (verified entrypoint-to-sink trace), NEEDS_VALIDATION (source-grounded candidate with an owner-executable verification recipe), or REJECTED (conclusively refuted by source controls). Any unresolved Critical finding, any CONFIRMED security vulnerability, or any Floor-Guard violation defaults the verdict to NO-GO in docs/reviews/{slug}-review.md.

When to reach for it

Where the work currently lives decides whether this is the right skill:

The work is… Reach for
Implementation completed and green tests passed /to-review @docs/spec/{slug}-spec.md @docs/plan/{slug}-plan.md
High-risk one-way doors (auth, payments, concurrency locks, DB migrations) /to-review (mandatory adversarial doubt cycle)
Targeted security & vulnerability audit on trust boundaries, auth, or LLM/MCP sinks /to-review security @docs/spec/{slug}-spec.md
A pure refactoring task claiming zero behavioral change /to-review (runs before/after diffing to prove parity)
Audit completed with defects or invariant breakages /to-fix (for First-Principles bug remediation) or /to-code
Audit approved with verdict GO, ready for public technical docs /to-docs @docs/spec/{slug}-spec.md

Prerequisites

  • Completed Implementation: Source code must be committed or staged on the active branch with tests green.
  • Upstream Specification & Plan: Target docs/spec/{slug}-spec.md and docs/plan/{slug}-plan.md must be available to evaluate conformance.
  • Runtime Evidence Mandate: Requires actual test runner output, terminal logs, or HTTP status codes. Static code reading alone can never grant a PASS.

What one run does

A single comprehensive quality review run executes eleven rigorous evaluation stages:

  1. Resilience Hierarchy Priority: Evaluates code strictly in order: Correct → Safe → Holds under load → Tested → Fast → Lean.
  2. Operating Mode Scoping: Selects between Full Quality & Release Audit (evaluating all 11 stages) and Focused Security Audit (/to-review security, focusing strictly on trust boundaries, asymmetric refutation, and the 14 security vectors).
  3. Verify the Tests First (Mutation Check): Proves test integrity by static assertion auditing or temporary worktree inversion, ensuring tests turn RED if the condition is inverted.
  4. Adversarial Doubt & 3-State Verdict Taxonomy: Evaluates candidate findings via Cloudflare-mandated refutation prompts into CONFIRMED (verified entrypoint-to-sink trace), NEEDS_VALIDATION (missing runtime facts with owner-executable recipes), or REJECTED (conclusively refuted).
  5. Runtime Evidence Gate & 4-State Taxonomy: Evaluates every acceptance criterion across 4 states: MET ✅, SPECCED BUT MISSING 🚫, SPECCED BUT NOT APPLIED ⚠️, or BLOCKED ⚠️.
  6. The 5 SOLID Principles & Floor-Guard Anti-Cheat: Audits SRP, OCP, LSP, ISP, and DIP. Inspects diff for cheating moves (suppressions, skipped tests, stubs, lowered ratchets).
  7. 14-Vector Defensive Security & LLM Hardening: Audits OWASP Top 10, Second-Order Injection, Tenant Isolation Lifecycle, AI/LLM Prompt Boundaries (The Guardrail Myth), SSRF/IMDSv1, CI/CD Expression Injection, and Secrets Hygiene.
  8. Universal Execution Safety Protocols: Enforces read-only source analysis, synthetic dummy principals, and zero DoS/stress attacks on live processes.
  9. Database, Caching & Performance Audit (EXPLAIN ANALYZE): Flags N+1 queries, validates composite index column order, and applies the Keep-or-Revert Gate to neutral optimizations.
  10. 30-Second Visual Topology & The Two Golden Questions: Synthesizes data flow into an ASCII topology and answers: Can you use the result? Can you use the method?
  11. Release Readiness Gate (GO | NO-GO): Authors docs/reviews/{slug}-review.md, issuing an automatic NO-GO verdict on any unresolved Critical finding, any CONFIRMED vulnerability, or Floor-Guard violation.

Common questions

All unit tests passed, why did /to-review issue a NO-GO verdict?

Passing tests prove nothing if they do not assert the right boundary or were weakened. Under the 4 Anti-Fabrication Rules, any Floor-Guard violation (such as adding @ts-ignore, skipping tests, or lowering quality ratchets in config files) or any CONFIRMED security vulnerability triggers an automatic, non-negotiable NO-GO verdict.

What is the difference between /to-review and /to-review security?

/to-review is the full 11-stage audit required for release sign-off, covering mutation checks, SOLID principles, boundary specialization, performance ledgers, and release gates. /to-review security is a fast, targeted adversarial audit focusing strictly on trust boundaries, asymmetric refutation, and the 14 defensive attack vectors without requiring unrelated benchmark metrics.

What is the 3-State Verdict Taxonomy (CONFIRMED, NEEDS_VALIDATION, REJECTED)?

In adversarial security review, the finding author cannot verify it alone. Candidates are evaluated against visible source and local evidence: CONFIRMED has an intact entrypoint-to-sink trace; NEEDS_VALIDATION indicates a credible source finding requiring missing runtime/cloud IAM facts (with a safe, executable verification recipe); REJECTED is conclusively disproven by visible code controls or framework invariants.

Why are system prompts not considered valid security boundaries (The Guardrail Myth)?

System prompts are probabilistic natural-language guidance, not deterministic security boundaries. Any security invariant (authorization, tenant isolation, tool argument validation, sink sanitization) must be enforced deterministically in code, schema decoders, and backend permissions.

Why doesn't the review agent fix the production code directly?

Separation of concerns. When an auditor edits production code, it creates confirmation bias and bypasses test boundaries. The auditor documents findings using the 4-part structure (What this is → Problem → Fix → If skipped) and hands off to /to-code for surgical execution.

What is the Keep-or-Revert Gate for performance optimizations?

Any optimization whose measured benchmark impact is within noise (neutral) is flagged for deletion. Speculative complexity without measurable gain is technical debt and must be reverted.

It's working if

  • It audits test assertion strength and runs mutation checks before trusting a green test suite.
  • Every PASS / MET claim in the report cites concrete test execution or runtime evidence.
  • It classifies security candidates into CONFIRMED, NEEDS_VALIDATION, or REJECTED with entrypoint-to-sink traces.
  • It automatically defaults to a NO-GO release verdict if any CONFIRMED security issue or Floor-Guard regression is detected.
  • All reported issues follow the standardized 4-part finding structure (or augmented security finding format).
  • It generates an intuitive 30-second ASCII topology diagram of the implemented system.
  • It strictly adheres to non-destructive execution safety and never modifies application source code directly during the review.

Where it fits

to-review is Phase 4 in the main idea-to-ship pipeline: 

/to-explore → /to-prd → /to-spec → /to-clarify → /to-plan → 🛑 PAUSE → /to-code → 🔍 /to-review → /to-docs

It receives the completed code implementation from /to-code. If approved (Verdict: GO), it hands off directly to /to-docs for user and API documentation. If defects are found (Verdict: NO-GO), it hands off to /to-fix or /to-code.