design-reviewlisted

This skill runs a structured design review of what has been built, measured against the design brief and the chosen aesthetic philosophy. > **CRITICAL — Visual Screenshot Capture** > > You MUST capture screenshots of the running application as part of every design review. Code review alone is insufficient — you need to see what the user sees. Follow the screenshot capture protocol in Step 3 below. This is not optional. ## Example prompts - "Review what I just built" - "Run a design critique on the landing page" - "Check this against the brief" - "Here's a screenshot. How does it look?" [paste screenshot] - "QA pass before I ship this" ## Process 1. **Read the brief.** Look for the active feature's brief at `.design/<feature-slug>/DESIGN_BRIEF.md`. If multiple feature folders exist under `.design/`, ask the user which feature to review. If no `.design/` folder exists, fall back to `DESIGN_BRIEF.md` in the project root. If neither exists, ask the user what the intended design direction was. 2. **Explore the built code.** Examine every component, page, and style file that was created or modified. Scan specifically for: - All new or modified components and their relationship to pre-existing components - Token/variable usage: are components using shared tokens or hardcoding values? - Duplicate components that should be consolidated - File naming and organization: do new files follow the project's conventions? - Understand what was actually built, not what was