review

A review is a list of things to change, each with a place, a fix and a reason. Anything else is an opinion. This skill produces the list.

Posture

• Evidence, not taste. A finding cites path/file.tsx:42 and shows what is there now. If you cannot point at it, you have not found it.
• Fix in the project's idiom. If they use Tailwind, the fix is a class. If they have tokens, the fix names the token. A finding that asks them to adopt a different stack is not a finding.
• A short list from a real inspection beats a long list padded to look thorough. Fifteen findings maximum. If there are more, the top fifteen by impact, and a line saying the rest exist.
• Deliberate choices are not findings. Density, radius, voice and palette are theirs unless they fail a hard rule (contrast, focus, hit size, missing state).
• Never say "consider". Say what to change.

1. Scope

State what is being reviewed before reviewing it: a screen, a flow, a component, a diff. If the request names a branch or PR, the scope is the changed files plus the surfaces they affect. If the request is a screen, the scope is that screen in all its states and at 375px and 1440px.

If the scope is too large to inspect credibly, narrow it to one complete flow, say which, and say what was excluded. Never imply that uninspected surfaces were reviewed.

2. Recon