review

Building is not done when the code runs. It is done when the code is correct.

AI moves fast. Fast means things get built that work on the surface but drift from the architecture, violate the design system, or miss edge cases that matter. This skill catches those things before they compound into bigger problems.

Run this after every feature. Before you move on.

What This Skill Does Not Do

It does not fix anything. It reports what it finds and lets the developer decide what matters and what to do about it. Fixing without understanding is how problems get buried, not solved.

---

Step 1 — Understand What Should Have Been Built

Before reviewing anything, establish the benchmark.

Read in this order:

• The implementation plan from /architect if one exists
• The feature description or task that was given
• Any relevant context files — architecture boundaries, code standards, design rules

If no plan exists, ask the developer to describe what the feature was supposed to do before reviewing. You cannot verify correctness without knowing what correct looks like.

---

Step 2 — Review in Three Layers

Layer 1 — Does it match the plan?

Compare what was built against what was planned.

Check:

• Every part of the feature description — is it all there?
• The decisions made during planning — are they reflected in the code?
• The scope — did the implementation stay within bounds or add things that were not asked for?

Flag anything that was planned but missing. Flag anything that was built but not planned.

Layer 2 — Does it respect the system?

This is where AI drift most commonly happens. The feature works, but it violates rules that the project depends on.

Check:

• Architecture boundaries — does code in the right place own the right responsibilities? No UI logic in API routes. No DB calls in components. Whatever the project's boundaries are — are they respected?
• Design system — are the correct tokens, classes, and patterns used? Any hardcoded values that should be variables? Any raw color classes that should use the design system?
• Code standards — naming conventions, file organisation, TypeScript strictness, error handling patterns — do they match what the project established?
• Existing patterns — does this feature introduce a new pattern when an existing one should have been used?