design-review

name

design-review

description

Review a diff or feature against Sleek Coach's design conventions (theme tokens, color and spacing scales, typography, component reuse, dark mode, accessibility). Use for the pre-commit design agent check, when the user asks for a "design review" / "UI review" / "token check" or whether a screen "matches the design system", or before committing changes that touch apps/mobile/src/components, apps/mobile/src/screens, apps/mobile/src/theme, or any .tsx UI surface. Reads docs/DESIGN_CONVENTIONS.md as the source of truth.

Design Review

Check a change against Sleek Coach's design conventions and report where it complies, where it violates a rule, and how to fix each violation.

This skill is a review tool, not a rubber stamp. Every rule in the conventions doc was earned by a real cleanup or defect; a change that violates one should be told so with the concrete way it degrades the product and the compliant fix, not waved through. Equally, do not invent violations: a rule that does not apply to the diff is simply not in play.

Step 1: Load the source of truth

Read docs/DESIGN_CONVENTIONS.md. Its rule sections and the review checklist at the bottom are authoritative; if the doc has changed, follow the changed version, not any summary reproduced elsewhere (including this skill).

Step 2: Gather the change under review

In priority order:

1. A target the user named (a PR number, branch, file, screen, or feature description).
2. The current working diff: git diff origin/main...HEAD, plus git diff HEAD if there are uncommitted changes (pre-commit reviews usually run before the commit exists).

If the diff is empty and no target was named, say so and stop. If the diff touches no mobile UI surface (nothing under apps/mobile/src besides tests, stores, or pure logic), say so and stop: this check is only for changes the user can see.

Step 3: Walk the review checklist

Go through the checklist at the bottom of the conventions doc in order, applying each item to the diff. Run the mechanical greps as written rather than eyeballing; the judgment items are calls you make by reading the full post-change files around each touched surface, not just the diff hunks: theme access, style arrays, and constants imports often live a few lines away from the changed hunk. Relocated code counts: when a refactor moves an old non-compliant value into a new file, review it as an addition (the move was the moment to fix it).

For each violation, report:

• file:line of the offending code.
• The rule it breaks, by section number from the doc.
• How it degrades the product: what the user would see (an invisible border in dark mode, a heading that disagrees with the ramp, a re-tuned scroll constant losing the #47-49 behavior).
• The compliant fix, naming the existing token or primitive the doc prescribes (theme.colors.outlineVariant, borderRadius.full, a typography preset, an existing src/components/ui/ component, a src/constants/ import).

Step 4: Report

Output, in this order:

1. Verdict: clean, clean with notes, or violations found.
2. Violations (if any), each with the four fields from Step 3, ordered by user impact.
3. Risks worth a look: things the diff makes easier to get wrong later, or rules it comes close to breaking.
4. Confirmed clean: the checklist areas the diff actually exercised and passed, so the reader knows what was checked rather than assuming everything was.

Keep the report tight: findings first, no praise, no restating the diff.