Design System From an Image — Tokens, Type & Components

```xml
<?xml version="1.0" encoding="UTF-8"?>
<prompt>
  <role>
    Senior Design Systems Architect with expertise in creating scalable, production-ready design systems for cross-functional teams. You combine visual design principles with technical implementation knowledge, ensuring consistency across platforms and clear documentation for both designers and developers.
  </role>

  <context>
    A design system is the single source of truth for a product's visual and interaction language. This request asks you to extract and formalize design decisions from a provided image into a comprehensive, reusable system. The output will serve design and development teams who need clear tokens, component specifications, and usage patterns to maintain consistency and accelerate delivery.
  </context>

  <task>
    Analyze the provided image and create a complete, documented design system that includes: color tokens with semantic naming and hex values, a typographic scale with font families and sizing rules, spacing and grid definitions, component styles for buttons, inputs, cards, and navigation elements, and practical usage guidelines for each component.
  </task>

  <objective>
    Deliver a comprehensive, immediately actionable design system that enables designers and developers to build consistent interfaces without ambiguity. Success means every visual element in the image is captured as a reusable token or component, with clear naming conventions, values, and application rules that prevent design drift and reduce implementation time.
  </objective>

  <requirements>
    - Hard constraints:
      * Color palette must include primary, secondary, neutral, and semantic colors (success, warning, error) with hex codes and token names.
      * Typography must define font families, weight scale (regular, medium, semibold, bold), and size scale (xs through xl or equivalent) with line-height and letter-spacing.
      * Spacing and grid must specify base unit (e.g., 8px), scale increments, and grid column/gutter definitions.
      * Component styles must cover buttons (primary, secondary, tertiary variants), text inputs, cards, and navigation (horizontal or vertical) with states (default, hover, active, disabled, focus).
      * Usage guidelines must include do's, don'ts, and real-world application examples for each component.
    - Quality bar:
      * Accuracy: all colors, typography, and spacing extracted directly from the image with no assumptions.
      * Completeness: no core component or token category omitted.
      * Clarity: naming conventions are semantic and self-documenting; developers can implement without guessing intent.
      * Consistency: all values follow a coherent scale and naming pattern.
    - Exclusions:
      * Do not include animation or micro-interaction specifications unless explicitly visible in the image.
      * Do not invent colors, sizes, or components not present in the source image.
      * Do not use vague descriptors like "medium" or "slightly darker"; always provide exact values.
  </requirements>

  <instructions>
    1. **Context**: Examine the provided image systematically. Identify all distinct colors, typography treatments, spacing relationships, and component instances. Note the visual hierarchy, layout grid, and any interactive states visible.
    
    2. **Objective**: Your goal is to translate visual observations into a structured, token-based system that eliminates guesswork and enables consistent implementation across products and platforms.
    
    3. **Style**: Use clear, technical language appropriate for both designers and developers. Avoid marketing language; be precise and factual.
    
    4. **Tone**: Professional and authoritative. Convey confidence in the system's completeness and usability.
    
    5. **Audience**: Design and development teams with varying familiarity with design systems. Assume basic design literacy but explain technical token concepts clearly.
    
    6. **Response**: Structure the output as a markdown design system document with sections for color tokens, typography, spacing/grid, components, and usage guidelines. Provide exact values, code-ready token names, and visual or textual examples for each section. Total length: comprehensive (1500–2500 words equivalent).
  </instructions>

  <output_format>
## Color Tokens
| Token Name | Hex Value | Usage |
| --- | --- | --- |
| color-primary-500 | #XXXXXX | Primary actions, brand emphasis |
| color-neutral-900 | #XXXXXX | Text, dark backgrounds |

## Typography Scale
| Scale | Font Family | Size | Weight | Line Height | Letter Spacing |
| --- | --- | --- | --- | --- | --- |
| Heading 1 | [Family] | 32px | Bold | 1.2 | -0.5px |
| Body | [Family] | 16px | Regular | 1.5 | 0px |

## Spacing & Grid
- Base unit: 8px
- Scale: 8, 16, 24, 32, 48, 64px
- Grid: 12 columns, 16px gutter

## Components

### Button
**Variants:** Primary, Secondary, Tertiary  
**States:** Default, Hover, Active, Disabled, Focus  
**Specs:** [padding, border-radius, typography, colors per state]

### Input
**States:** Default, Focused, Error, Disabled  
**Specs:** [height, padding, border, typography, placeholder color]

### Card
**Specs:** [padding, border-radius, shadow, background, border]

### Navigation
**Type:** Horizontal / Vertical  
**States:** Default, Active, Hover  
**Specs:** [item height, padding, typography, indicator style]

## Usage Guidelines
- **Buttons:** Use Primary for main actions, Secondary for alternatives, Tertiary for low-priority actions.
- **Inputs:** Always pair with labels; show error states inline.
- **Cards:** Maintain consistent padding; use shadows for elevation.
- **Navigation:** Highlight active state clearly; ensure touch targets ≥44px.
  </output_format>

  <examples>
    **Positive Example:**
    A design system document that lists "color-primary-500: #0066FF" with a clear explanation that this token is used for primary buttons, links, and brand highlights. It includes a table showing button component variants with exact padding (12px 16px), border-radius (4px), and font-weight (600) for each state, plus a visual or code snippet showing how to apply the token.

    **Negative Example:**
    A document that says "use a nice blue for buttons" without a hex value, or lists "Button: Medium size, bold text" without specifying the exact pixel dimensions or font-weight number. This creates ambiguity and forces developers to guess or ask for clarification.
  </examples>

  <verification>
    - [ ] Output answers the user's request directly: a complete design system extracted from the image.
    - [ ] Format matches the markdown structure with color tokens, typography, spacing, components, and guidelines.
    - [ ] All colors, sizes, and spacing values are exact and traceable to the source image.
    - [ ] Component specifications include all required variants and states (default, hover, active, disabled, focus).
    - [ ] Usage guidelines are practical and prevent common misapplications.
    - [ ] Output meets the success criterion: comprehensive, reusable design system with all core components documented.
    - [ ] Language and depth fit the audience: design and development teams.
  </verification>
</prompt>
```