Extract component specs from a UI reference
Turn visible UI controls into traceable tokens and component specifications, separating observations from estimates and proposed states.

Recipe typeUI design
Output formatEvidence table + tokens + component specs
DeliverablesObserved / estimated / proposed
Version1.0
Turn visible UI controls into traceable tokens and component specifications, separating observations from estimates and proposed states. A compact direction to help the next screen feel deliberate, specific, and easy to remix.
02 / Prompt
Analyze the supplied UI reference images and extract reusable control styles into evidence-backed component specifications. Preserve the visual language; do not recreate the whole page or present inference as observation.
INPUT
References: [clear UI screenshots; label page, theme and state when supplying several]
Scope: [regions/components; blank means visible controls]
Known specifications, optional: [original viewport, screenshot scale, font, existing CSS/tokens]
Additional components, optional: [actually required components/states; blank means no invented complete library]
Language/use: [Chinese/English; design handoff or implementation]
METHOD
1. Confirm that readable UI controls are present. If images are absent, decorative only or unreadable in critical areas, explain the gap, ask up to three blocking questions and wait. State actual coverage. Analyze different themes or styles separately rather than averaging them.
2. Inventory visible buttons, inputs, selectors, cards, navigation and badges. Record instance locations and observed states. Inspect each control's fill, text, border, radius, shadow, typography, dimensions and spacing. Do not infer control colors from page whitespace, photos or decoration.
3. Label each value as original specification, image observation, visual estimate or proposed addition, with image/region and evidence. Claim exact extraction only after actually accessing source CSS or using sampling tools. With unknown scaling, pixel distances are estimates in image space. Mark uncertain HEX values, font names, shadows and states as approximate or unknown; do not claim contrast compliance.
4. Consolidate repeated styles into primitive values, semantic roles and component references. Distinguish surface, text, border and action colors; extract status colors only when visible. Derive type, spacing and radius relationships from repeated evidence rather than imposing a preset scale. Avoid excessive tokens for isolated pixels.
5. Propose only missing states/components actually requested. Mark them as proposed additions and separate them from observations. A static screenshot cannot establish hover, focus, disabled, responsive behavior or interaction outcomes. Preserve observed rules and mark accessibility/interaction suggestions for implementation testing.
6. Check that referenced tokens exist, names are consistent and themes remain separate. Report measurement and estimation coverage. Claim no tool use, rendering or testing that was not performed.
DELIVER IN ORDER
A. Inventory: component / image and region / visible state / coverage.
B. Evidence table: property / value / unit / evidence type / origin / uncertainty.
C. Tokens: primitive → semantic → component references; copyable CSS custom properties. Put unknown values in comments rather than executable numeric values. Optional JSON is an explicitly custom structure, without unverified standards-compatibility claims.
D. Component specs: dimensions, spacing, type, color, border, radius, shadow and observed states; separate proposed-state table.
E. Checks and confirmations: visual consistency, keyboard focus, legibility, target sizes and missing-state test plan. These are recommendations, not certification.
BOUNDARIES
Extract component styles, not complete page clones or palette inspiration libraries. Reuse no protected marks or assets. Invent no fonts, exact measurements, hidden states, test results or saved files. Without file tools, deliver complete text/code blocks.
Independent site adaptation of wuchengfei / screenshot-to-design-system's control-region extraction, primitive/semantic/component tokens and observation/inference distinction (MIT). Reduces full-library completion and tool workflows; not the complete original Skill: https://github.com/WCF900905/screenshot-to-design-system/blob/030e3007a82991113a04b9e0454824b4ad2ef9c7/SKILL.md .03 / Negative prompt
invented measurements, guessed font identities presented as facts, unobserved states presented as observations, whole-page copying, decorative colors treated as control tokens, claimed tool execution or certificationRecipe typeComponent extraction
Output formatEvidence table + tokens + component specs
DeliverablesObserved / estimated / proposed
Version1.0