Discovery Checklist

Inspect only the files needed to answer these questions before editing.

Before expanding scope, identify exactly which page, component, or feature surface the user asked to vary. Keep the rest of the experience stable unless the user explicitly asks for broader page redesign.

Product And Design Intent

Is there a stated design philosophy in README*, docs/**, CONTRIBUTING*, or nearby design docs?
Does the repo describe brand tone, density preferences, or component usage rules?
Are there obvious examples of the same kind of surface elsewhere in the app?

App Structure

Which router is in use?
Where do page/layout entry points live?
Is there an existing internal-only preview, lab, or story route?
What is the smallest safe place to add a preview without disturbing production paths?

Styling System

Are styles driven by Tailwind, CSS modules, CSS-in-JS, plain CSS, or a component library?
Where do colors, spacing, radius, shadows, typography, and breakpoints come from?
Are there theme tokens or CSS variables that must be reused?

Component Primitives

What shared components should be reused for buttons, cards, inputs, dialogs, tabs, and layout?
Are there common container or page-shell components that the preview should preserve?
Do components carry motion, focus, or accessibility conventions that must remain intact?

Data And Content

Can the preview reuse live data flow safely?
If not, what is the smallest local fixture needed for a fair comparison?
How can content stay constant across variations so the user compares layout and interaction rather than copy changes?
What existing content is already part of the requested surface, and what extra fluff should be avoided because the user did not ask for it?

Validation

What are the lightest relevant commands for lint, typecheck, test, or build?
Can the app run locally for a browser check?
If it can run, what route should be opened to validate the preview?

2.0 KiB Raw Permalink Blame History