Design Spec Extractor

Problem

When engineers receive UI screenshots, web URLs, or multiple page designs, the hard part is not merely “reading” the design, but converting visual judgments into reusable rules: Is #1D4ED8 a primary color or an accent? Is 16px padding, gutter, or component spacing? Is the font Inter or a system default?

design-spec-extractor turns design evidence into structured specifications instead of vague style commentary. It is useful before design reviews, before frontend componentization, or when documenting a design system.

How It Works

The skill first classifies input: local images, image URLs, webpage URLs, or mixed sources. For web URLs, it can capture screenshots and computed styles when available; otherwise it falls back to HTML/CSS clue extraction.

Analysis covers six dimensions:
- Visual style: tone, key characteristics, and use cases
- Color system: primary, secondary, functional, background, text, and border colors
- Typography: scale, weight, line height, alignment, and candidate fonts when confidence is low
- Layout and spacing: grid, container width, module gaps, and responsive tendencies
- Component patterns: buttons, cards, navigation, tables, empty states, and other recurring elements
- Design principles: consistency, hierarchy, and product goals behind the choices

Outputs can include analysis.json, design_spec.md, design_spec.html, and optionally design_spec.pptx. Source previews are kept to support evidence tracing.

Boundaries

This skill is not for legal standards, general photo aesthetics, or replacing design-to-code. If assets are blurry, pages require login, or dynamic content fails, provide screenshots first. If only a local component is supplied, output should be a local specification, not a full design system.