| name | website-to-design-md |
| description | Generate a layered, replication-oriented design analysis package from a live website, screenshots, or HTML/CSS evidence. Use when the user wants a corpus-style DESIGN.md plus stronger template and page-composition guidance for implementation or close visual reproduction. |
Website to DESIGN.md
This skill turns a website into a high-quality layered design analysis package.
It preserves the original corpus-style DESIGN.md output, but adds stronger separation between:
- global visual system rules
- template-specific rules
- page-specific composition
- evidence confidence and provenance
Use it when the user wants not only a strong design-system reference, but also better support for reconstruction, implementation, or close stylistic reproduction.
When To Use This Skill
Use this skill when the user wants to:
- reverse-engineer a website into a corpus-style
DESIGN.md
- capture both site-wide design rules and template-level differences
- recreate a website's style with higher fidelity than a single design-system summary usually allows
- produce inputs for downstream UI generation, prototyping, or implementation
- understand where certainty is high, medium, or low across extracted claims
This skill is especially appropriate when the user asks for:
- close reproduction
- style cloning
- implementation guidance
- page blueprinting
- template analysis
- stronger fidelity checks
Do not use this skill when the user only wants:
- a general design critique
- frontend code without analysis artifacts
- a moodboard or inspiration summary
- brand copy or marketing messaging
Output Modes
This skill supports two output modes.
Default Mode
Use default mode when the user wants design-system understanding only.
Output:
Replication Mode
Use replication mode when the user wants closer visual reconstruction or implementation guidance.
Output:
DESIGN.mdTEMPLATE_MAP.mdPAGE_BLUEPRINT.md- optional
EVIDENCE_REPORT.md
Trigger replication mode when the user asks to:
- replicate a site's style
- rebuild or recreate a site visually
- implement pages from the extracted system
- compare implementation output against the live site
Expected Inputs
The skill works best when at least one of these is available:
- a live website URL
- multiple screenshots across more than one page or state
- HTML/CSS/DOM evidence
- DevTools output such as computed styles, CSS variables, or loaded fonts
If the user provides only a homepage URL, automatically discover representative same-domain inner pages before writing the final artifacts.
Preferred evidence order:
- Live website plus DevTools-style browser inspection
- Live website plus browser snapshots and DOM inspection
- Screenshots plus HTML/CSS evidence
- Screenshots only
Expected Outputs
DESIGN.md
Purpose:
- describe the stable, site-wide design system in corpus style
Important constraint:
- keep it focused on global or strongly repeated rules
- do not overload it with page-by-page blueprint content
TEMPLATE_MAP.md
Purpose:
- describe what changes between templates
This should answer:
- what is stable across templates
- what is specific to homepage, listing, detail, pricing, docs, or other roles
- what should not be generalized site-wide
PAGE_BLUEPRINT.md
Purpose:
- describe page composition and pacing
This should answer:
- how key pages are structured
- how sections stack
- how columns, hero proportions, and rhythm behave
EVIDENCE_REPORT.md
Purpose:
- record evidence mode, inspected pages, confidence, provenance, and unresolved uncertainty
Write it when:
- the user asks for stronger auditability
- the user wants replication mode
- the environment or evidence quality makes traceability especially useful
Workflow
Step -1: Check Inspection Tooling
Before analysis, check whether a Chrome DevTools-style MCP server or equivalent browser inspection tools are available.
If available, prefer them over screenshot-only analysis.
Use them to collect:
- homepage plus representative inner pages
- screenshots or viewport captures
- DOM or accessibility-tree snapshots
- computed styles for visible primitives
- CSS variables, font declarations, and reusable tokens when accessible
- interaction-state evidence only when directly observed
- breakpoint clues when inspectable
When only a homepage URL is provided, discover representative inner pages from visible same-domain links in navigation, featured cards, article lists, product areas, pricing links, docs links, or footer links.
Avoid exhaustive crawling.
Stay on the same domain unless the user explicitly expands scope.
Use checklists/evidence-checklist.md as the default evidence workflow.
Step 0: Calibrate Against The Corpus
Before analyzing the target site, re-read representative corpus DESIGN.md files so the output matches repository conventions rather than a generic design-system format.
At minimum, sample:
- one minimalist or black-and-white system
- one editorial or serif-led system
- one dark or developer-tool system
- one colorful or expressive system
Match:
- section order
- writing density
- formatting style
- component granularity
- conservative evidence language
Step 1: Determine Mode And Scope
Before drafting anything, decide:
- default mode or replication mode
- requested scope
- whether implementation fidelity is a primary goal
If the user is asking for style replication, implementation guidance, or close comparison against a live site, use replication mode.
Step 2: Build A Template Matrix
Do not move directly from page browsing to writing.
First classify the inspected pages into a template matrix.
Minimum template matrix fields:
- page role
- representative URL or artifact
- dominant surface/background behavior
- heading behavior
- list/card structure
- navigation treatment
- media/image behavior
- utility or form presence
- notable composition traits
Recommended matrix coverage on multi-template sites:
- homepage
- listing or archive page
- detail page
- one secondary promotional or themed page
- one account, onboarding, pricing, docs, or form page when present
If a site has fewer available templates, record the limitation explicitly.
Step 3: Capture Evidence Per Template
For each sampled template, collect:
- screenshot or viewport capture for pacing and composition
- DOM or accessibility-tree snapshot for structure
- representative computed styles for visible primitives
- tokens and font declarations when inspectable
At minimum, sample these primitives:
body- primary display heading
- secondary heading
- body paragraph
- standard text link
- primary button
- secondary or ghost button when present
- card or framed container
- navigation link or tab
- input or form field when present
- badge, tag, or pill when present
Also capture when observable:
- hover
- focus
- active / pressed
- sticky behavior
- expanded / collapsed navigation
- selected states
- desktop and mobile layout changes
If a state cannot be observed, write Not clearly observed.
Step 4: Classify Findings By Scope
Before writing final artifacts, label findings as one of:
globaltemplate-specificpage-specificuncertain
Also record:
- support count or supporting templates
- whether a claim is directly inspected or visually inferred
- confidence level: high, medium, low
Use this logic:
- put stable repeated rules into
DESIGN.md
- put template differences into
TEMPLATE_MAP.md
- put layout sequencing and composition into
PAGE_BLUEPRINT.md
- put provenance and unresolved ambiguity into
EVIDENCE_REPORT.md
Step 5: Extract Additional Layers
In addition to normal design-system extraction, capture these additional layers.
Typography Fingerprints
Do not rely only on named font families.
Also capture:
- condensed vs regular vs expanded feel
- stroke and contrast character
- uppercase usage policy
- average letter-spacing behavior by role
- line-height discipline
- headline-to-body contrast
- substitution guidance when proprietary fonts are unavailable
Image And Media Language
Capture:
- documentary vs polished vs illustrative vs abstract
- crop style
- color grading tendencies
- whether images lead or support the page
- relationship between images and captions
- whether graphics behave like evidence, atmosphere, or decoration
Composition Rhythm
Capture:
- section contrast sequence across the page
- above-the-fold density
- hero-to-body transition style
- card count per row
- major content widths
- where the page visually pauses
Step 6: Write Artifacts
Use:
Rules:
- keep
DESIGN.md corpus-aligned and specification-oriented
- keep
TEMPLATE_MAP.md comparative and scope-aware
- keep
PAGE_BLUEPRINT.md layout-oriented and approximate rather than falsely precise
- keep
EVIDENCE_REPORT.md factual, compact, and audit-friendly
If the execution environment supports file writing and the user provides a destination, write the artifacts there.
Step 7: Optional Verification Loop
When replication fidelity matters, add a verification loop.
- Generate or inspect a lightweight prototype or implementation pass.
- Compare it against the live site with browser inspection.
- Classify mismatches into:
- font mismatch
- composition mismatch
- spacing mismatch
- color mismatch
- image-language mismatch
- interaction mismatch
- Reflect the mismatch back into the analysis artifacts.
This step is optional but strongly recommended in replication mode.
Formatting Rules
- Write all artifacts in English unless the user explicitly requests another language.
- Keep
DESIGN.md compatible with the awesome-design-md corpus format.
- Prefer direct, operational language over decorative commentary.
- Use conservative phrasing whenever certainty is partial.
- Do not allow a homepage-specific visual move to silently become a global rule.
Quality Bar
A strong output should:
- preserve a high-quality corpus-style
DESIGN.md
- separate stable system rules from template-specific rules
- make page composition explicit enough to guide implementation
- expose confidence and evidence provenance when needed
- reduce downstream drift during reconstruction or replication
Final Check Before Delivering
Before finishing, confirm:
- the mode was chosen correctly
- at least two templates were inspected on multi-template sites unless explicitly impossible
- typography, colors, and components are based on repeated evidence rather than hero-only impressions
DESIGN.md stays focused on stable system rules- any template-specific or page-specific rules are routed into secondary artifacts instead of being overgeneralized
