claudecode-boilerplate/.claude/skills/ui-design/SKILL.md

name	description	allowed-tools
ui-design	Guide for creating the UI/UX design specification (design brief, UI blueprint JSON, and SVG wireframes). Use when defining or updating the design under docs/design/.	Read, Write, Edit

UI Design Skill

This skill explains how to create an AI-readable, implementation-ready UI/UX design specification. It prefers structured, machine-consumable descriptions over vague visual descriptions.

Core Principle

The source of truth is structured text/JSON. Visual images (SVG) are references for humans, not inputs for code generation.

Prefer describing what a component is and how it behaves over describing what it looks like. "A primary button with label 'Save' that triggers action:save" is better than "a nice blue button in the corner".

Outputs

This skill produces four kinds of artifacts under docs/design/:

1. screen-inventory.md — an exhaustive checklist of every screen the requirements imply (always created first)
2. design-brief.md — the UI/UX direction (human-readable, but concrete)
3. ui-blueprint.json — the source of truth for UI generation (machine-readable)
4. screens/*.svg — visual wireframes for human review (derived from the blueprint)

Prerequisites

Before creating the design, read:

• docs/product-requirements.md
• docs/functional-design.md
• docs/architecture.md

The design must serve the product requirements and stay consistent with the functional design.

Creating screen-inventory.md (always first)

Never design screens from memory of the requirements — a screen that is not on a written list will be forgotten (the classic miss: a list screen exists but the create/add screen does not). Build the inventory before the brief or the blueprint:

1. Walk every user story in the PRD and every flow in the functional design; list every screen the user needs to complete it end-to-end. If a story cannot be completed with the screens listed so far, the missing screens go on the list.
2. Apply CRUD coverage per entity: for each domain object the user manages, explicitly decide list/overview, detail, create/add, edit, and delete confirmation — include each unless the requirements clearly exclude it. Modal/dialog/inline forms count as inventory entries too (record the presentation); they still need blueprint entries and wireframes.
3. Add supporting screens: authentication, settings, onboarding, search results, empty states, error / not-found — wherever the requirements imply them.

Each entry is a checkbox item with screen-id, title, purpose, source requirement, how it is reached, presentation (page / modal / drawer), and key elements. End the file with a traceability table mapping every user story to the screen ids that fulfill it — both directions must be covered (no story without screens, no screen without a source).

Check entries off ([x]) as their screens are added to ui-blueprint.json. The blueprint is not complete while any entry is unchecked.

Creating design-brief.md

A concrete, opinionated document. Avoid vague phrases like "modern and clean" without elaboration. Include every section below:

• Target users — who the UI is for, and their key contexts/constraints
• Design concept — the one-paragraph idea the UI embodies
• Visual mood — concrete descriptors (density, light/dark, rounding, motion amount)
• Layout principles — grid, alignment, content width, spacing rhythm
• Navigation principles — primary navigation pattern, depth, back behavior
• Accessibility considerations — target contrast, touch-target sizes, focus visibility, font scaling
• Platform-specific notes — how the design adapts to web / Flutter / WinUI 3
• Examples of preferred UI style — concrete references and why they fit
• Examples of UI style to avoid — anti-patterns to stay away from

Creating ui-blueprint.json (source of truth)

This is the most important file. It must be valid JSON and fully describe the app's UI structure so that a generator can produce Web, Flutter, or WinUI 3 code without guessing.

Required top-level fields

• app.name
• app.platformTargets — e.g. ["web", "flutter", "winui3"]
• app.style — short style summary string
• screens — array of screen objects
• components — map of reusable component definitions

Screen object shape

Each screen has:

• id — stable identifier (used as the SVG filename)
• title
• route
• layout — type + spacing tokens (e.g. { "type": "vertical", "padding": "lg", "gap": "md" })
• components — a tree of component nodes

Component node shape

Each node has:

• type — e.g. header, card, text, button, list, input, image, nav
• variant — optional, must exist in the component's variants
• role — optional semantic role (e.g. title, subtitle, body)
• content / label — text content where applicable
• action — user action, e.g. navigate:details, submit, toggle:filters
• children — nested component nodes

Reusable component definition

"components": {
  "button": {
    "variants": ["primary", "secondary", "ghost"],
    "states": ["default", "hover", "pressed", "disabled"]
  }
}

Example (excerpt)

{
  "app": {
    "name": "Example App",
    "platformTargets": ["web", "flutter", "winui3"],
    "style": "friendly, modern, rounded, calm"
  },
  "screens": [
    {
      "id": "home",
      "title": "Home",
      "route": "/",
      "layout": { "type": "vertical", "padding": "lg", "gap": "md" },
      "components": [
        { "type": "header", "title": "Dashboard", "subtitle": "Welcome back" },
        {
          "type": "card",
          "variant": "primary",
          "children": [
            { "type": "text", "role": "title", "content": "Start here" },
            { "type": "button", "label": "Open", "action": "navigate:details" }
          ]
        }
      ]
    }
  ],
  "components": {
    "button": {
      "variants": ["primary", "secondary", "ghost"],
      "states": ["default", "hover", "pressed", "disabled"]
    },
    "card": {
      "variants": ["primary", "secondary", "danger"]
    }
  }
}

Rules

• Every variant referenced in a screen must exist in components[type].variants.
• Every spacing/radius/color name referenced in layout/components must exist in design-tokens.json.
• Use action: prefixes consistently: navigate:<screen-id>, submit, toggle:<id>, open:<id>, etc.
• One screen = one route. Do not overload a screen with multiple routes.
• Keep the blueprint free of hard-coded pixel values; reference token names instead.

Creating SVG wireframes (screens/*.svg)

• Generate one SVG per screen, named <screen-id>.svg.
• The SVG is a low-fidelity wireframe, not a pixel-perfect mock. Use boxes, labels, and placeholders.
• It must reflect the component tree of its screen in ui-blueprint.json.
• If the blueprint and an SVG disagree, the blueprint wins. Regenerate the SVG.
• SVGs exist only so humans can review the design at a glance.

Consistency Checklist

Before finishing:

• Every entry in screen-inventory.md is checked off and exists in the blueprint (same id).
• Every user story can be completed end-to-end using only blueprint screens and actions — every entity that can be created, edited, or deleted has a screen or modal for each operation.
• Every screen in the blueprint has a matching SVG.
• Every variant used in a screen is declared in components.
• Every token name used in the blueprint exists in design-tokens.json.
• The brief and the blueprint describe the same app (same screens, same navigation).
• No hard-coded values in the blueprint.