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 — Read the Project Standards

Before reviewing anything, read the project's context and rules files if they exist:

• AGENTS.md, .agents/ — agent rules and project standards
• ARCHITECTURE.md — system design and boundaries
• CONVENTIONS.md — naming and code patterns
• ui-registry.md — UI consistency patterns

These files define what "correct" looks like for this project. You cannot review without knowing the rules.

Step 2 — Understand What Should Have Been Built

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 3 — Review in Four 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, variables, classes, and patterns used? Any hardcoded values that should use design tokens? Any raw values that should reference 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? Does it duplicate logic that already exists as a helper or utility?
• Code reuse — is there duplicated logic that should be extracted into a shared helper? Did the feature reuse existing abstractions where it should have?

Layer 3 — Is it secure?

Check whether the feature handles security correctly. Not every feature needs this layer — but any feature that touches user data, auth, external services, or inputs must be checked.

• Input validation — are all user inputs validated and sanitized before use?
• Auth and authorization — are protected routes, actions, and data guarded? Can an unauthorized user access something they shouldn't?
• Sensitive data — is anything logged, exposed in error messages, or stored that shouldn't be? Are API keys, tokens, or user data handled properly?
• Injection risks — any raw SQL, innerHTML, dangerouslySetInnerHTML, or unescaped output?
• Data exposure — does the API return more data than the client needs? Are private fields filtered out?

If the feature doesn't touch anything sensitive, mark this layer as PASS and move on. Do not force security concerns where none exist.

Layer 4 — Is it production ready?

Check:

• Error handling — what happens when things go wrong? Are errors caught and handled, or does the feature silently fail? Are error messages useful?
• Edge cases — empty states, loading states, missing data, null values — are these handled?
• Test coverage — do critical paths have tests? Are edge cases tested? If no tests exist for important logic, flag it.
• Performance smells — any obvious N+1 queries, missing async patterns, unnecessary recomputations, or unbounded list fetches without pagination?
• Console errors — any errors or warnings in the browser or terminal?
• Obvious bugs — anything that would clearly break for a real user?

Step 4 — Report What You Found

After completing all four layers, produce a clear report. Do not bury issues. Do not soften them. Report honestly so the developer can make informed decisions.

Reference specific files and line ranges when applicable.

## Review — [Feature Name]

### Layer 1 — Plan alignment
[PASS / ISSUES FOUND]
[List any gaps between what was planned and what was built]

### Layer 2 — System integrity
[PASS / ISSUES FOUND]
[List any architecture, design, code standard, or reuse violations]
[Reference: file path — line range — what is wrong]

### Layer 3 — Security
[PASS / NOT APPLICABLE / ISSUES FOUND]
[List any input validation, auth, data exposure, or injection issues]
[Reference: file path — line range — what is wrong]

### Layer 4 — Production readiness
[PASS / ISSUES FOUND]
[List any error handling gaps, edge cases, missing tests, performance smells, or obvious bugs]
[Reference: file path — line range — what is wrong]

### Summary
[X] issues found across [Y] layers.

[If no issues: "No issues found. This feature is ready to ship."]
[If issues: "Resolve the above before moving to the next feature."]

Step 5 — Let the Developer Decide

After presenting the report, stop. Do not start fixing. Do not suggest fixes unless the developer asks.

Wait for the developer to:

• Ask you to fix a specific issue
• Tell you an issue is intentional and can be ignored
• Confirm everything is resolved and ready to move on

The developer owns the quality decision. You inform it.

Severity Guide

Not all issues are equal. Use this to help the developer prioritise:

Critical — fix before moving on

• Architecture boundary violations that will break future features
• Security issues — exposed data, missing auth, injection risks
• Missing error handling that causes silent failures
• Functionality that was planned but completely missing

Important — fix soon

• Design system drift that will cause UI inconsistency
• Code standard violations that will compound across the codebase
• Edge cases that a real user will encounter
• Missing tests for critical business logic
• Duplicated code that should be extracted

Minor — fix when convenient

• Naming inconsistencies that do not affect behaviour
• Missing optimisations that don't affect UX
• Style issues that do not affect the design system

Label each issue with its severity so the developer can triage quickly.

The Standard

The question this skill answers is not "does it work?"

The question is "is it correct?"

Working and correct are not the same thing. A feature can work today and break the project tomorrow. Review exists to catch the difference.