website-to-design-md

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:

• DESIGN.md

Replication Mode

Use replication mode when the user wants closer visual reconstruction or implementation guidance.

Output:

• DESIGN.md
• TEMPLATE_MAP.md
• PAGE_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:

1. Live website plus DevTools-style browser inspection
2. Live website plus browser snapshots and DOM inspection
3. Screenshots plus HTML/CSS evidence
4. 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:

• global
• template-specific
• page-specific
• uncertain

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:

• prompts/website-to-design-md.md
• templates/DESIGN.md.template.md
• templates/TEMPLATE_MAP.template.md
• templates/PAGE_BLUEPRINT.template.md
• templates/EVIDENCE_REPORT.template.md

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.

1. Generate or inspect a lightweight prototype or implementation pass.
2. Compare it against the live site with browser inspection.
3. Classify mismatches into:
   • font mismatch
   • composition mismatch
   • spacing mismatch
   • color mismatch
   • image-language mismatch
   • interaction mismatch
4. 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