design-review
Design Review
Adapted from OneRedOak/claude-code-workflows' design-review (MIT; the ecosystem-standard design-review methodology — Stripe/Airbnb/Linear-caliber standards, "Live Environment First" principle), re-adapted for a web stack: browser automation (e.g. Playwright or an agent-browser CLI) against a real browser.
Who runs this: an executor or QA subagent dispatched by the coordinator — with this skill loaded. The coordinator reads the report, not the pixels.
Core principle — Live Environment First: assess the interactive experience in a real browser BEFORE static analysis or code reading. Actual rendered experience over theoretical correctness. Static screenshots alone and green tests alone are NOT a design review — both together, plus interaction, are.
Canon sources (the "design principles doc" slot) — identify your project's equivalents before starting:
- Static mockups, if the project keeps them (e.g.
design/*.htmlwith a route/screen inventory) — binding canon for visuals. - The requirements/design doc that sets the performance and theming bar (e.g. light + dark mode).
- Any binding frontend skills or standards docs (interaction rules, asset budgets).
Phase 0: Preparation
- Read the task and the diff under review; understand intent and scope.
- Identify the canon mockup screen(s) for every changed route (both themes, if the project is theme-sensitive).
- Confirm the local environment is running (e.g.
ddev describe); get the reachableBASE_URL.