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.

• "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"

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 planned.
3. Capture screenshots of the running application.
   This step is mandatory. Do not skip it. Do not rely only on user-provided screenshots.

   Screenshot Tool Priority

   Try each option in order. Use the first one that is available:
   1. Playwright MCP (preferred). Check if the

      plugin-playwright-playwright

      MCP server is available. If it is, use it — it gives you precise control over viewport sizing, full-page captures, and file naming.
   2. Cursor IDE Browser (second choice). If Playwright MCP is not available, use the

      cursor-ide-browser

      MCP server's

      browser_take_screenshot

      tool instead. It has the same core capabilities.
   3. Ask the user (last resort). If neither MCP server nor in-app browser is available, you MUST ask the user to provide screenshots manually. Be specific about what you need:
      • "I don't have access to a browser tool. To complete the visual review I need screenshots of the running application. Please provide:"
      • A full-page screenshot at desktop width (1280px)
      • A full-page screenshot at tablet width (768px)
      • A full-page screenshot at mobile width (375px)
      • Dark mode variants (if applicable)
      • Any specific component or interactive state you want reviewed
      • Ask the user to paste/attach the images directly in chat, or to save them into the

        screenshots/

        folder themselves.
      • Do not skip the visual review. Wait for the user to provide screenshots before proceeding with the checklist.

   Screenshot Save Location

   All screenshots MUST be saved to a

   screenshots/

   subfolder inside the feature's

   .design/

   directory — the same folder where

   DESIGN_BRIEF.md

   and other design flow files live.
   Path pattern:

   .design/<feature-slug>/screenshots/

   If the brief lives at

   .design/onboarding-flow/DESIGN_BRIEF.md

   , screenshots go to

   .design/onboarding-flow/screenshots/

   . Create the folder if it does not exist.
   If no

   .design/

   folder exists (legacy project or standalone review), fall back to a

   screenshots/

   folder in the project root.
   Use descriptive filenames that encode what was captured:

   .design/
   └── onboarding-flow/
       ├── DESIGN_BRIEF.md
       ├── DESIGN_REVIEW.md
       └── screenshots/
           ├── review-homepage-desktop-1280.png
           ├── review-homepage-tablet-768.png
           ├── review-homepage-mobile-375.png
           ├── review-homepage-dark-mode-desktop-1280.png
           └── review-card-component-hover.png

   Screenshot Capture Protocol

   a. Navigate to the application. Ask the user for the URL if not obvious from the project (e.g.,

   http://localhost:3000

   ). Use

   browser_navigate

   to open it.
   b. Capture responsive breakpoints. At minimum, capture these three viewports for every key page/view:

   Breakpoint	Width × Height	Filename suffix
   Mobile	375 × 812	-mobile-375
   Tablet	768 × 1024	-tablet-768
   Desktop	1280 × 800	-desktop-1280

   Use

   browser_resize

   to set the viewport before each screenshot. Use

   browser_take_screenshot

   with

   fullPage: true

   to capture the entire scrollable page, and save with the

   filename

   parameter pointing to the

   screenshots/

   folder.
   Playwright MCP example sequence (assuming feature slug is

   onboarding-flow

   ):

   1. browser_navigate → { url: "http://localhost:3000" }
   2. browser_resize   → { width: 1280, height: 800 }
   3. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-desktop-1280.png", fullPage: true }
   4. browser_resize   → { width: 768, height: 1024 }
   5. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-tablet-768.png", fullPage: true }
   6. browser_resize   → { width: 375, height: 812 }
   7. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-mobile-375.png", fullPage: true }

   c. Capture interactive states (when relevant).
   • Hover states on buttons, cards, links
   • Focus states on form fields
   • Open states on dropdowns, modals, menus
   • Error/success states on forms
   • Loading and empty states
   d. Capture dark mode (if the project supports it). Toggle dark mode and repeat the responsive breakpoint captures with

   -dark-mode

   in the filename.
   e. Capture specific components. If the review focuses on a particular component, use the

   element

   and

   ref

   parameters to screenshot just that element.

   Analyze Every Screenshot

   After capturing, visually analyze each screenshot against the design brief. For each screenshot:
   • Compare against the brief's aesthetic direction
   • Check visual hierarchy: is the most important element the most prominent?
   • Check spacing consistency: do margins and padding look even and intentional?
   • Check color: does the palette match the brief's direction?
   • Check typography: are font sizes, weights, and spacing visually correct?
   • Check responsive adaptation: does the layout properly reorganize (not just shrink)?
   • Note rendering issues that code review alone would miss (font loading failures, broken images, layout overflow, z-index problems, incorrect border-radius, color mismatches)
   Reference specific screenshots by filename in the review output so findings are traceable.
4. Run the review checklist below. For each category, note what passes and what needs refinement. Be specific. Reference exact components, files, line numbers, and screenshot filenames.
5. Produce a prioritized refinement list. Group issues by severity:
   • Must fix: Broken functionality, accessibility failures, major deviations from the brief.
   • Should fix: Inconsistencies, missing states, responsive issues.
   • Could improve: Polish, animation refinement, typography fine-tuning.
6. Save the review as

   DESIGN_REVIEW.md

   inside the feature's

   .design/<feature-slug>/

   folder (next to

   DESIGN_BRIEF.md

   ). If no

   .design/

   folder exists, save to the project root. Include a "Screenshots Captured" section listing all screenshots taken with their paths. Present the review directly as well if the user prefers.

• Is the most important content the most visually prominent on each page/view?
• Does the type scale create clear levels of importance (heading, subheading, body, caption)?
• Do interactive elements (buttons, links, inputs) have enough visual weight to be found without hunting?
• Is there a clear reading order? Can you trace where the eye goes first, second, third?

• Are spacing values consistent? Check padding and margins against the established scale (4px/8px base or whatever the project uses).
• Are colors used consistently? Check that the same semantic meaning always maps to the same color (primary actions, errors, success states, disabled states).
• Are border radii, shadow values, and font sizes reused from a shared set, or are there one-off values?
• Do similar components look and behave similarly? (e.g., all cards, all form fields, all buttons within a category.)

• Does the implementation match the named philosophy from the brief?
• Would someone looking at this immediately recognize the intended aesthetic direction?
• Are there elements that break the aesthetic (a generic component in an otherwise distinctive interface, a conflicting font, an out-of-place color)?
• Does the level of detail match the philosophy? (Minimalist designs should not have unnecessary decoration. Maximalist designs should not have empty, unfinished areas.)

• Do existing components from the codebase appear correctly, or were they reimplemented?
• Are new components following the same API patterns (props, naming, file organization) as existing ones?
• Are there duplicate components that should be consolidated?

• Do interactive elements have all necessary states: default, hover, focus, active, disabled?
• Do form fields have states for: empty, filled, error, success, disabled?
• Are loading states handled? Empty states?
• Do transitions and animations match the philosophy's motion guidelines?
• Is there visual feedback for every user action?

• Does the layout work at mobile (375px), tablet (768px), and desktop (1280px+)?
• Do components adapt appropriately? (Not just shrink, but reorganize when needed.)
• Is touch target size adequate on mobile (minimum 44x44px)?
• Does text remain readable at all breakpoints? No text too small, no lines too wide (max 65-75 characters).

• Color contrast: Do text/background combinations meet WCAG AA (4.5:1 for body text, 3:1 for large text)?
• Keyboard navigation: Can every interactive element be reached and activated with keyboard alone?
• Focus indicators: Are focus rings visible and styled consistently?
• Semantic HTML: Are headings in order? Are landmarks used (main, nav, header, footer)? Are form labels associated?
• Screen reader: Do images have alt text? Do icons have labels? Are decorative elements hidden from assistive technology?
• Motion: Is there a reduced-motion media query for users who need it?

• Is the font actually loading? (Check for FOIT/FOUT flash.)
• Are line lengths comfortable for reading (45-75 characters on body text)?
• Is line height appropriate (1.4-1.6 for body, tighter for headings)?
• Is the type scale intentional, or are there arbitrary sizes?

• If the project has dark mode tokens, are they applied correctly?
• Are all color values using CSS variables (not hardcoded hex values that won't switch)?
• Does the dark palette feel intentional for the chosen philosophy, or is it a simple inversion?
• Are shadows adjusted for dark mode (darker, more transparent)?
• Do accent colors maintain sufficient contrast against dark backgrounds?
• Is there a working toggle mechanism or

  prefers-color-scheme

  support?

• Was the layout built mobile-first (using

  min-width

  media queries, not

  max-width

  )?
• Does the mobile layout work at 375px without horizontal scrolling?
• Is navigation adapted for mobile (not just a desktop nav that overflows)?
• Are touch targets at least 44x44px?
• Is body text at least 16px on mobile?

screenshots/review-[page]-desktop-1280.png

screenshots/review-[page]-tablet-768.png

screenshots/review-[page]-mobile-375.png

All screenshots are in

.design/<feature-slug>/screenshots/

.

1. [Issue]: [Specific description with file/component reference]. See [

   screenshots/[relevant-screenshot].png

   ]. Fix: [concrete suggestion].

1. [Issue]: [Description]. See [

   screenshots/[relevant-screenshot].png

   ]. Fix: [suggestion].

1. [Issue]: [Description]. Suggestion: [idea].