Use this workflow when the source is a live page you are permitted to inspect and you want more evidence than a screenshot alone can provide.
What this workflow examines
HTML structure
Headings, navigation, sections, controls, calls to action, and component relationships.
Stylesheets and variables
Repeated colors, font stacks, spacing, radii, shadows, gradients, transitions, keyframes, and breakpoints.
Rendered screenshot
Visible hierarchy, composition, contrast, density, imagery, and first-viewport context.
Relevant scripts
Evidence of scroll reveals, toggles, counters, parallax, animation libraries, and state changes.
A review-first extraction workflow
Enter a permitted public URL
Use a page you own, control, or are otherwise allowed to analyze. Choose a representative page with the visual language you want to document.
Collect code and visual evidence
The analyzer fetches page assets within safety and size limits, extracts recurring design signals, and captures a rendered reference image.
Map values to semantic roles
Raw values become roles such as canvas, surface, primary text, border, action, card radius, section spacing, and motion easing.
Generate DESIGN.md and a live preview
The output documents tokens, component recipes, responsive behavior, motion, accessibility expectations, and explicit guardrails.
Review before production use
Compare the preview with the source, remove framework noise, verify contrast and states, and keep only rules that are actually intentional.
Example: raw website evidence becomes an agent-ready rule
Before: raw evidence
Observed evidence
#4F46E5 appears in primary buttons and active links
16px radius repeats on cards
24px and 48px dominate section spacing
Transitions use approximately 180ms ease-outAfter: useful context
DESIGN.md guidance
- Use action-primary for the main CTA and active navigation only.
- Cards use radius-lg: 16px; controls use radius-sm: 10px.
- Compose sections on a 24px internal / 48px external rhythm.
- Interactive changes use motion-fast: 180ms ease-out.What the output should contain
- Semantic tokens: named color, typography, spacing, radius, elevation, layout, and motion roles.
- Component recipes: anatomy, variants, states, content constraints, and when to reuse each pattern.
- Responsive guidance: container behavior, breakpoints, stacking, overflow, density, and mobile priorities.
- Guardrails: visual choices the implementation must not invent or apply outside approved contexts.
- Validation evidence: a representative preview and a record of assumptions, unknowns, and intentional exceptions.
Important limitations
- Client-rendered states may not exist in the initial HTML.
- Large framework bundles can contain unused values.
- One page may not represent every product surface.
- Third-party assets and protected brand content should not be copied.
Responsible use: analyze only material you own, control, or are permitted to study. Extract reusable design principles; do not copy protected content, private code, trademarks, or distinctive assets without permission.
Frequently asked questions
Can a website extractor identify every design token?
No automated extractor can prove that every discovered value is intentional. Treat the output as evidence to review, consolidate, and validate against representative pages.
Is extracting a design system the same as cloning a website?
No. A design-system workflow documents reusable visual rules. It should not copy protected content, trademarks, private code, or distinctive assets without permission.
Why combine CSS analysis with a screenshot?
Code reveals exact values and behavior, while a screenshot shows which values are visually important and how they work together in the rendered page.
What should I do with the generated DESIGN.md?
Store it with your project, reference it from your coding-agent rules, review it when the UI changes, and keep executable components and tokens as the final implementation truth.