USP

Unlike generic UI generation, this skill automatically loads and saves design system decisions to `system.md`, preventing design drift and ensuring consistent application of spacing, colors, and depth across all UI components.

Use cases

• 01Building user dashboards with metrics cards
• 02Creating admin panels for developer tools
• 03Designing settings pages for SaaS apps
• 04Crafting collaborative tools with consistent UI
• 05Developing data-heavy analytics interfaces

Detected files (7)

• .claude/skills/interface-design/SKILL.mdskill
  Show content (20045 bytes)

  ---
  name: interface-design
  description: This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns).
  ---
  
  # Interface Design
  
  Build interface design with craft and consistency.
  
  ## Scope
  
  **Use for:** Dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces.
  
  **Not for:** Landing pages, marketing sites, campaigns. Redirect those to `/frontend-design`.
  
  ---
  
  # The Problem
  
  You will generate generic output. Your training has seen thousands of dashboards. The patterns are strong.
  
  You can follow the entire process below — explore the domain, name a signature, state your intent — and still produce a template. Warm colors on cold structures. Friendly fonts on generic layouts. "Kitchen feel" that looks like every other app.
  
  This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win.
  
  The process below helps. But process alone doesn't guarantee craft. You have to catch yourself.
  
  ---
  
  # Where Defaults Hide
  
  Defaults don't announce themselves. They disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed.
  
  **Typography feels like a container.** Pick something readable, move on. But typography isn't holding your design — it IS your design. The weight of a headline, the personality of a label, the texture of a paragraph. These shape how the product feels before anyone reads a word. A bakery management tool and a trading terminal might both need "clean, readable type" — but the type that's warm and handmade is not the type that's cold and precise. If you're reaching for your usual font, you're not designing.
  
  **Navigation feels like scaffolding.** Build the sidebar, add the links, get to the real work. But navigation isn't around your product — it IS your product. Where you are, where you can go, what matters most. A page floating in space is a component demo, not software. The navigation teaches people how to think about the space they're in.
  
  **Data feels like presentation.** You have numbers, show numbers. But a number on screen is not design. The question is: what does this number mean to the person looking at it? What will they do with it? A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space. If you're reaching for number-on-label, you're not designing.
  
  **Token names feel like implementation detail.** But your CSS variables are design decisions. `--ink` and `--parchment` evoke a world. `--gray-700` and `--surface-2` evoke a template. Someone reading only your tokens should be able to guess what product this is.
  
  The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design. The moment you stop asking "why this?" is the moment defaults take over.
  
  ---
  
  # Intent First
  
  Before touching code, answer these. Not in your head — out loud, to yourself or the user.
  
  **Who is this human?**
  Not "users." The actual person. Where are they when they open this? What's on their mind? What did they do 5 minutes ago, what will they do 5 minutes after? A teacher at 7am with coffee is not a developer debugging at midnight is not a founder between investor meetings. Their world shapes the interface.
  
  **What must they accomplish?**
  Not "use the dashboard." The verb. Grade these submissions. Find the broken deployment. Approve the payment. The answer determines what leads, what follows, what hides.
  
  **What should this feel like?**
  Say it in words that mean something. "Clean and modern" means nothing — every AI says that. Warm like a notebook? Cold like a terminal? Dense like a trading floor? Calm like a reading app? The answer shapes color, type, spacing, density — everything.
  
  If you cannot answer these with specifics, stop. Ask the user. Do not guess. Do not default.
  
  ## Every Choice Must Be A Choice
  
  For every decision, you must be able to explain WHY.
  
  - Why this layout and not another?
  - Why this color temperature?
  - Why this typeface?
  - Why this spacing scale?
  - Why this information hierarchy?
  
  If your answer is "it's common" or "it's clean" or "it works" — you haven't chosen. You've defaulted. Defaults are invisible. Invisible choices compound into generic output.
  
  **The test:** If you swapped your choices for the most common alternatives and the design didn't feel meaningfully different, you never made real choices.
  
  ## Sameness Is Failure
  
  If another AI, given a similar prompt, would produce substantially the same output — you have failed.
  
  This is not about being different for its own sake. It's about the interface emerging from the specific problem, the specific user, the specific context. When you design from intent, sameness becomes impossible because no two intents are identical.
  
  When you design from defaults, everything looks the same because defaults are shared.
  
  ## Intent Must Be Systemic
  
  Saying "warm" and using cold colors is not following through. Intent is not a label — it's a constraint that shapes every decision.
  
  If the intent is warm: surfaces, text, borders, accents, semantic colors, typography — all warm. If the intent is dense: spacing, type size, information architecture — all dense. If the intent is calm: motion, contrast, color saturation — all calm.
  
  Check your output against your stated intent. Does every token reinforce it? Or did you state an intent and then default anyway?
  
  ---
  
  # Product Domain Exploration
  
  This is where defaults get caught — or don't.
  
  Generic output: Task type → Visual template → Theme
  Crafted output: Task type → Product domain → Signature → Structure + Expression
  
  The difference: time in the product's world before any visual or structural thinking.
  
  ## Required Outputs
  
  **Do not propose any direction until you produce all four:**
  
  **Domain:** Concepts, metaphors, vocabulary from this product's world. Not features — territory. Minimum 5.
  
  **Color world:** What colors exist naturally in this product's domain? Not "warm" or "cool" — go to the actual world. If this product were a physical space, what would you see? What colors belong there that don't belong elsewhere? List 5+.
  
  **Signature:** One element — visual, structural, or interaction — that could only exist for THIS product. If you can't name one, keep exploring.
  
  **Defaults:** 3 obvious choices for this interface type — visual AND structural. You can't avoid patterns you haven't named.
  
  ## Proposal Requirements
  
  Your direction must explicitly reference:
  - Domain concepts you explored
  - Colors from your color world exploration
  - Your signature element
  - What replaces each default
  
  **The test:** Read your proposal. Remove the product name. Could someone identify what this is for? If not, it's generic. Explore deeper.
  
  ---
  
  # The Mandate
  
  **Before showing the user, look at what you made.**
  
  Ask yourself: "If they said this lacks craft, what would they mean?"
  
  That thing you just thought of — fix it first.
  
  Your first output is probably generic. That's normal. The work is catching it before the user has to.
  
  ## The Checks
  
  Run these against your output before presenting:
  
  - **The swap test:** If you swapped the typeface for your usual one, would anyone notice? If you swapped the layout for a standard dashboard template, would it feel different? The places where swapping wouldn't matter are the places you defaulted.
  
  - **The squint test:** Blur your eyes. Can you still perceive hierarchy? Is anything jumping out harshly? Craft whispers.
  
  - **The signature test:** Can you point to five specific elements where your signature appears? Not "the overall feel" — actual components. A signature you can't locate doesn't exist.
  
  - **The token test:** Read your CSS variables out loud. Do they sound like they belong to this product's world, or could they belong to any project?
  
  If any check fails, iterate before showing.
  
  ---
  
  # Craft Foundations
  
  ## Subtle Layering
  
  This is the backbone of craft. Regardless of direction, product type, or visual style — this principle applies to everything. You should barely notice the system working. When you look at Vercel's dashboard, you don't think "nice borders." You just understand the structure. The craft is invisible — that's how you know it's working.
  
  ### Surface Elevation
  
  Surfaces stack. A dropdown sits above a card which sits above the page. Build a numbered system — base, then increasing elevation levels. In dark mode, higher elevation = slightly lighter. In light mode, higher elevation = slightly lighter or uses shadow.
  
  Each jump should be only a few percentage points of lightness. You can barely see the difference in isolation. But when surfaces stack, the hierarchy emerges. Whisper-quiet shifts that you feel rather than see.
  
  **Key decisions:**
  - **Sidebars:** Same background as canvas, not different. Different colors fragment the visual space into "sidebar world" and "content world." A subtle border is enough separation.
  - **Dropdowns:** One level above their parent surface. If both share the same level, the dropdown blends into the card and layering is lost.
  - **Inputs:** Slightly darker than their surroundings, not lighter. Inputs are "inset" — they receive content. A darker background signals "type here" without heavy borders.
  
  ### Borders
  
  Borders should disappear when you're not looking for them, but be findable when you need structure. Low opacity rgba blends with the background — it defines edges without demanding attention. Solid hex borders look harsh in comparison.
  
  Build a progression — not all borders are equal. Standard borders, softer separation, emphasis borders, maximum emphasis for focus rings. Match intensity to the importance of the boundary.
  
  **The squint test:** Blur your eyes at the interface. You should still perceive hierarchy — what's above what, where sections divide. But nothing should jump out. No harsh lines. No jarring color shifts. Just quiet structure.
  
  This separates professional interfaces from amateur ones. Get this wrong and nothing else matters.
  
  ## Infinite Expression
  
  Every pattern has infinite expressions. **No interface should look the same.**
  
  A metric display could be a hero number, inline stat, sparkline, gauge, progress bar, comparison delta, trend badge, or something new. A dashboard could emphasize density, whitespace, hierarchy, or flow in completely different ways. Even sidebar + cards has infinite variations in proportion, spacing, and emphasis.
  
  **Before building, ask:**
  - What's the ONE thing users do most here?
  - What products solve similar problems brilliantly? Study them.
  - Why would this interface feel designed for its purpose, not templated?
  
  **NEVER produce identical output.** Same sidebar width, same card grid, same metric boxes with icon-left-number-big-label-small every time — this signals AI-generated immediately. It's forgettable.
  
  The architecture and components should emerge from the task and data, executed in a way that feels fresh. Linear's cards don't look like Notion's. Vercel's metrics don't look like Stripe's. Same concepts, infinite expressions.
  
  ## Color Lives Somewhere
  
  Every product exists in a world. That world has colors.
  
  Before you reach for a palette, spend time in the product's world. What would you see if you walked into the physical version of this space? What materials? What light? What objects?
  
  Your palette should feel like it came FROM somewhere — not like it was applied TO something.
  
  **Beyond Warm and Cold:** Temperature is one axis. Is this quiet or loud? Dense or spacious? Serious or playful? Geometric or organic? A trading terminal and a meditation app are both "focused" — completely different kinds of focus. Find the specific quality, not the generic label.
  
  **Color Carries Meaning:** Gray builds structure. Color communicates — status, action, emphasis, identity. Unmotivated color is noise. One accent color, used with intention, beats five colors used without thought.
  
  ---
  
  # Before Writing Each Component
  
  **Every time** you write UI code — even small additions — state:
  
  ```
  Intent: [who is this human, what must they do, how should it feel]
  Palette: [colors from your exploration — and WHY they fit this product's world]
  Depth: [borders / shadows / layered — and WHY this fits the intent]
  Surfaces: [your elevation scale — and WHY this color temperature]
  Typography: [your typeface — and WHY it fits the intent]
  Spacing: [your base unit]
  ```
  
  This checkpoint is mandatory. It forces you to connect every technical choice back to intent.
  
  If you can't explain WHY for each choice, you're defaulting. Stop and think.
  
  ---
  
  # Design Principles
  
  ## Token Architecture
  
  Every color in your interface should trace back to a small set of primitives: foreground (text hierarchy), background (surface elevation), border (separation hierarchy), brand, and semantic (destructive, warning, success). No random hex values — everything maps to primitives.
  
  ### Text Hierarchy
  
  Don't just have "text" and "gray text." Build four levels — primary, secondary, tertiary, muted. Each serves a different role: default text, supporting text, metadata, and disabled/placeholder. Use all four consistently. If you're only using two, your hierarchy is too flat.
  
  ### Border Progression
  
  Borders aren't binary. Build a scale that matches intensity to importance — standard separation, softer separation, emphasis, maximum emphasis. Not every boundary deserves the same weight.
  
  ### Control Tokens
  
  Form controls have specific needs. Don't reuse surface tokens — create dedicated ones for control backgrounds, control borders, and focus states. This lets you tune interactive elements independently from layout surfaces.
  
  ## Spacing
  
  Pick a base unit and stick to multiples. Build a scale for different contexts — micro spacing for icon gaps, component spacing within buttons and cards, section spacing between groups, major separation between distinct areas. Random values signal no system.
  
  ## Padding
  
  Keep it symmetrical. If one side has a value, others should match unless content naturally requires asymmetry.
  
  ## Depth
  
  Choose ONE approach and commit:
  - **Borders-only** — Clean, technical. For dense tools.
  - **Subtle shadows** — Soft lift. For approachable products.
  - **Layered shadows** — Premium, dimensional. For cards that need presence.
  - **Surface color shifts** — Background tints establish hierarchy without shadows.
  
  Don't mix approaches.
  
  ## Border Radius
  
  Sharper feels technical. Rounder feels friendly. Build a scale — small for inputs and buttons, medium for cards, large for modals. Don't mix sharp and soft randomly.
  
  ## Typography
  
  Build distinct levels distinguishable at a glance. Headlines need weight and tight tracking for presence. Body needs comfortable weight for readability. Labels need medium weight that works at smaller sizes. Data needs monospace with tabular number spacing for alignment. Don't rely on size alone — combine size, weight, and letter-spacing.
  
  ## Card Layouts
  
  A metric card doesn't have to look like a plan card doesn't have to look like a settings card. Design each card's internal structure for its specific content — but keep the surface treatment consistent: same border weight, shadow depth, corner radius, padding scale.
  
  ## Controls
  
  Native `<select>` and `<input type="date">` render OS-native elements that cannot be styled. Build custom components — trigger buttons with positioned dropdowns, calendar popovers, styled state management.
  
  ## Iconography
  
  Icons clarify, not decorate — if removing an icon loses no meaning, remove it. Choose one icon set and stick with it. Give standalone icons presence with subtle background containers.
  
  ## Animation
  
  Fast micro-interactions, smooth easing. Larger transitions can be slightly longer. Use deceleration easing. Avoid spring/bounce in professional interfaces.
  
  ## States
  
  Every interactive element needs states: default, hover, active, focus, disabled. Data needs states too: loading, empty, error. Missing states feel broken.
  
  ## Navigation Context
  
  Screens need grounding. A data table floating in space feels like a component demo, not a product. Include navigation showing where you are in the app, location indicators, and user context. When building sidebars, consider same background as main content with border separation rather than different colors.
  
  ## Dark Mode
  
  Dark interfaces have different needs. Shadows are less visible on dark backgrounds — lean on borders for definition. Semantic colors (success, warning, error) often need slight desaturation. The hierarchy system still applies, just with inverted values.
  
  ---
  
  # Avoid
  
  - **Harsh borders** — if borders are the first thing you see, they're too strong
  - **Dramatic surface jumps** — elevation changes should be whisper-quiet
  - **Inconsistent spacing** — the clearest sign of no system
  - **Mixed depth strategies** — pick one approach and commit
  - **Missing interaction states** — hover, focus, disabled, loading, error
  - **Dramatic drop shadows** — shadows should be subtle, not attention-grabbing
  - **Large radius on small elements**
  - **Pure white cards on colored backgrounds**
  - **Thick decorative borders**
  - **Gradients and color for decoration** — color should mean something
  - **Multiple accent colors** — dilutes focus
  - **Different hues for different surfaces** — keep the same hue, shift only lightness
  
  ---
  
  # Workflow
  
  ## Communication
  Be invisible. Don't announce modes or narrate process.
  
  **Never say:** "I'm in ESTABLISH MODE", "Let me check system.md..."
  
  **Instead:** Jump into work. State suggestions with reasoning.
  
  ## Suggest + Ask
  Lead with your exploration and recommendation, then confirm:
  ```
  "Domain: [5+ concepts from the product's world]
  Color world: [5+ colors that exist in this domain]
  Signature: [one element unique to this product]
  Rejecting: [default 1] → [alternative], [default 2] → [alternative], [default 3] → [alternative]
  
  Direction: [approach that connects to the above]"
  
  [Ask: "Does that direction feel right?"]
  ```
  
  ## If Project Has system.md
  Read `.interface-design/system.md` and apply. Decisions are made.
  
  ## If No system.md
  1. Explore domain — Produce all four required outputs
  2. Propose — Direction must reference all four
  3. Confirm — Get user buy-in
  4. Build — Apply principles
  5. **Evaluate** — Run the mandate checks before showing
  6. Offer to save
  
  ---
  
  # After Completing a Task
  
  When you finish building something, **always offer to save**:
  
  ```
  "Want me to save these patterns for future sessions?"
  ```
  
  If yes, write to `.interface-design/system.md`:
  - Direction and feel
  - Depth strategy (borders/shadows/layered)
  - Spacing base unit
  - Key component patterns
  
  ### What to Save
  
  Add patterns when a component is used 2+ times, is reusable across the project, or has specific measurements worth remembering. Don't save one-off components, temporary experiments, or variations better handled with props.
  
  ### Consistency Checks
  
  If system.md defines values, check against them: spacing on the defined grid, depth using the declared strategy throughout, colors from the defined palette, documented patterns reused instead of reinvented.
  
  This compounds — each save makes future work faster and more consistent.
  
  ---
  
  # Deep Dives
  
  For more detail on specific topics:
  - `references/principles.md` — Code examples, specific values, dark mode
  - `references/validation.md` — Memory management, when to update system.md
  - `references/critique.md` — Post-build craft critique protocol
  
  # Commands
  
  - `/interface-design:status` — Current system state
  - `/interface-design:audit` — Check code against system
  - `/interface-design:extract` — Extract patterns from code
  - `/interface-design:critique` — Critique your build for craft, then rebuild what defaulted
  

• .claude/commands/init.mdcommand
  Show content (2986 bytes)

  ---
  name: interface-design:init
  description: Build UI with craft and consistency. For interface design (dashboards, apps, tools) — not marketing sites.
  ---
  
  ## Required Reading — Do This First
  
  Before writing any code, read this file completely:
  
  1. `../skills/interface-design/SKILL.md` — the foundation, principles, craft knowledge, and checks
  
  Do not skip this. The craft knowledge is in this file.
  
  ---
  
  **Scope:** Dashboards, apps, tools, admin panels. Not landing pages or marketing sites.
  
  ## Intent First — Answer Before Building
  
  Before touching code, answer these out loud:
  
  **Who is this human?** Not "users." Where are they? What's on their mind? A teacher at 7am with coffee is not a developer debugging at midnight.
  
  **What must they accomplish?** Not "use the dashboard." The verb. Grade submissions. Find the broken deployment. Approve the payment.
  
  **What should this feel like?** In words that mean something. "Clean" means nothing. Warm like a notebook? Cold like a terminal? Dense like a trading floor?
  
  If you cannot answer these with specifics, stop and ask the user. Do not guess. Do not default.
  
  ## Before Writing Each Component
  
  State the intent AND the technical approach:
  
  ```
  Intent: [who, what they need to do, how it should feel]
  Palette: [foundation + accent — and WHY these colors fit the product's world]
  Depth: [borders / subtle shadows / layered — and WHY]
  Surfaces: [your elevation scale — and WHY this temperature]
  Typography: [your typeface choice — and WHY it fits the intent]
  Spacing: [your base unit]
  ```
  
  Every choice must be explainable. If your answer is "it's common" or "it works" — you haven't chosen. You've defaulted.
  
  **The test:** If another AI given a similar prompt would produce the same output, you have failed. The interface must emerge from THIS user, THIS problem, THIS intent.
  
  ## Communication
  
  Be invisible. Don't announce modes or narrate process.
  
  **Never say:** "I'm in ESTABLISH MODE", "Let me check system.md..."
  
  **Instead:** Jump into work. State suggestions with reasoning.
  
  ## Suggest + Ask
  
  Lead with your exploration and recommendation, then confirm:
  ```
  "Domain: [concepts from this product's world]
  Color world: [colors that exist in this domain]
  Signature: [one element unique to this product]
  
  Direction: [approach that connects to the above]"
  
  [AskUserQuestion: "Does that direction feel right?"]
  ```
  
  ## Flow
  
  1. Read the required files above (always — even if system.md exists)
  2. Check if `.interface-design/system.md` exists
  3. **If exists**: Apply established patterns from system.md
  4. **If not**: Assess context, suggest direction, get confirmation, build
  
  The skill files contain the craft principles. system.md contains project-specific decisions. You need both.
  
  ## After Every Task
  
  Offer to save when you finish building UI:
  
  "Want me to save these patterns to `.interface-design/system.md`?"
  
  Always offer — new patterns should be captured whether system.md exists or not.
  

• .claude/commands/status.mdcommand
  Show content (1026 bytes)

  ---
  name: interface-design:status
  description: Show current design system state including direction, tokens, and patterns.
  ---
  
  # interface-design status
  
  Show current design system state.
  
  ## What to Show
  
  **If `.interface-design/system.md` exists:**
  
  Display:
  ```
  Design System: [Project Name]
  
  Direction: [Precision & Density / Warmth / etc]
  Foundation: [Cool slate / Warm stone / etc]
  Depth: [Borders-only / Subtle shadows / Layered]
  
  Tokens:
  - Spacing base: 4px
  - Radius scale: 4px, 6px, 8px
  - Colors: [count] defined
  
  Patterns:
  - Button Primary (36px h, 16px px, 6px radius)
  - Card Default (border, 16px pad)
  - [other patterns...]
  
  Last updated: [from git or file mtime]
  ```
  
  **If no system.md:**
  
  ```
  No design system found.
  
  Options:
  1. Build UI → system will be established automatically
  2. Run /interface-design:extract → pull patterns from existing code
  ```
  
  ## Implementation
  
  1. Read `.interface-design/system.md`
  2. Parse direction, tokens, patterns
  3. Format and display
  4. If no system, suggest next steps
  

• .claude/commands/audit.mdcommand
  Show content (1577 bytes)

  ---
  name: interface-design:audit
  description: Check existing code against your design system for spacing, depth, color, and pattern violations.
  ---
  
  # interface-design audit
  
  Check existing code against your design system.
  
  ## Usage
  
  ```
  /audit <path>     # Audit specific file/directory
  /audit            # Audit common UI paths
  ```
  
  ## What to Check
  
  **If `.interface-design/system.md` exists:**
  
  1. **Spacing violations**
     - Find spacing values not on defined grid
     - Example: 17px when base is 4px
  
  2. **Depth violations**
     - Borders-only system → flag shadows
     - Subtle system → flag layered shadows
     - Allow ring shadows (0 0 0 1px)
  
  3. **Color violations**
     - If palette defined → flag colors not in palette
     - Allow semantic grays
  
  4. **Pattern drift**
     - Find buttons not matching Button pattern
     - Find cards not matching Card pattern
  
  **Report format:**
  ```
  Audit Results: src/components/
  
  Violations:
    Button.tsx:12 - Height 38px (pattern: 36px)
    Card.tsx:8 - Shadow used (system: borders-only)
    Input.tsx:20 - Spacing 14px (grid: 4px, nearest: 12px or 16px)
  
  Suggestions:
    - Update Button height to match pattern
    - Replace shadow with border
    - Adjust spacing to grid
  ```
  
  **If no system.md:**
  
  ```
  No design system to audit against.
  
  Create a system first:
  1. Build UI → establish system automatically
  2. Run /extract → create system from existing code
  ```
  
  ## Implementation
  
  1. Check for system.md
  2. Parse system rules
  3. Read target files (tsx, jsx, css, scss)
  4. Compare against rules
  5. Report violations with suggestions
  

• .claude/commands/critique.mdcommand
  Show content (4378 bytes)

  ---
  name: interface-design:critique
  description: Critique your build for craft, then rebuild what defaulted.
  ---
  
  # Critique
  
  Your first build shipped the structure. Now look at it the way a design lead reviews a junior's work — not asking "does this work?" but "would I put my name on this?"
  
  ## The Gap
  
  There's a distance between correct and crafted. Correct means the layout holds, the grid aligns, the colors don't clash. Crafted means someone cared about every decision down to the last pixel. You can feel the difference immediately — the way you tell a hand-thrown mug from an injection-molded one. Both hold coffee. One has presence.
  
  Your first output lives in correct. This command pulls it toward crafted.
  
  ## See the Composition
  
  Step back. Look at the whole thing.
  
  Does the layout have rhythm? Great interfaces breathe unevenly — dense tooling areas give way to open content, heavy elements balance against light ones, the eye travels through the page with purpose. Default layouts are monotone: same card size, same gaps, same density everywhere. Flatness is the sound of no one deciding.
  
  Are proportions doing work? A 280px sidebar next to full-width content says "navigation serves content." A 360px sidebar says "these are peers." The specific number declares what matters. If you can't articulate what your proportions are saying, they're not saying anything.
  
  Is there a clear focal point? Every screen has one thing the user came here to do. That thing should dominate — through size, position, contrast, or the space around it. When everything competes equally, nothing wins and the interface feels like a parking lot.
  
  ## See the Craft
  
  Move close. Pixel-close.
  
  The spacing grid is non-negotiable — every value a multiple of 4, no exceptions — but correctness alone isn't craft. Craft is knowing that a tool panel at 16px padding feels workbench-tight while the same card at 24px feels like a brochure. The same number can be right in one context and lazy in another. Density is a design decision, not a constant.
  
  Typography should be legible even squinted. If size is the only thing separating your headline from your body from your label, the hierarchy is too weak. Weight, tracking, and opacity create layers that size alone can't.
  
  Surfaces should whisper hierarchy. Not thick borders, not dramatic shadows — quiet tonal shifts where you feel the depth without seeing it. Remove every border from your CSS mentally. Can you still perceive the structure through surface color alone? If not, your surfaces aren't working hard enough.
  
  Interactive elements need life. Every button, link, and clickable region should respond to hover and press. Not dramatically — a subtle shift in background, a gentle darkening. Missing states make an interface feel like a photograph of software instead of software.
  
  ## See the Content
  
  Read every visible string as a user would. Not checking for typos — checking for truth.
  
  Does this screen tell one coherent story? Could a real person at a real company be looking at exactly this data right now? Or does the page title belong to one product, the article body to another, and the sidebar metrics to a third?
  
  Content incoherence breaks the illusion faster than any visual flaw. A beautifully designed interface with nonsensical content is a movie set with no script.
  
  ## See the Structure
  
  Open the CSS and find the lies — the places that look right but are held together with tape.
  
  Negative margins undoing a parent's padding. Calc() values that exist only as workarounds. Absolute positioning to escape layout flow. Each is a shortcut where a clean solution exists. Cards with full-width dividers use flex column and section-level padding. Centered content uses max-width with auto margins. The correct answer is always simpler than the hack.
  
  ## Again
  
  Look at your output one final time.
  
  Ask: "If they said this lacks craft, what would they point to?"
  
  That thing you just thought of — fix it. Then ask again.
  
  The first build was the draft. The critique is the design.
  
  ## Process
  
  1. Open the file you just built
  2. Walk through each section above: composition, craft, content, structure
  3. Identify every place you defaulted instead of decided
  4. Rebuild those parts — from the decision, not from a patch
  5. Do not narrate the critique to the user. Do the work. Show the result.
  

• .claude/commands/extract.mdcommand
  Show content (1679 bytes)

  ---
  name: interface-design:extract
  description: Extract design patterns from existing code to create a system.md file.
  ---
  
  # interface-design extract
  
  Extract design patterns from existing code to create a system.
  
  ## Usage
  
  ```
  /extract          # Extract from common UI paths
  /extract <path>   # Extract from specific directory
  ```
  
  ## What to Extract
  
  **Scan UI files (tsx, jsx, vue, svelte) for:**
  
  1. **Repeated spacing values**
     ```
     Found: 4px (12x), 8px (23x), 12px (18x), 16px (31x), 24px (8x)
     → Suggests: Base 4px, Scale: 4, 8, 12, 16, 24
     ```
  
  2. **Repeated radius values**
     ```
     Found: 6px (28x), 8px (5x)
     → Suggests: Radius scale: 6px, 8px
     ```
  
  3. **Button patterns**
     ```
     Found 8 buttons:
     - Height: 36px (7/8), 40px (1/8)
     - Padding: 12px 16px (6/8), 16px (2/8)
     → Suggests: Button pattern: 36px h, 12px 16px padding
     ```
  
  4. **Card patterns**
     ```
     Found 12 cards:
     - Border: 1px solid (10/12), none (2/12)
     - Padding: 16px (9/12), 20px (3/12)
     → Suggests: Card pattern: 1px border, 16px padding
     ```
  
  5. **Depth strategy**
     ```
     box-shadow found: 2x
     border found: 34x
     → Suggests: Borders-only depth
     ```
  
  **Then prompt:**
  ```
  Extracted patterns:
  
  Spacing:
    Base: 4px
    Scale: 4, 8, 12, 16, 24, 32
  
  Depth: Borders-only (34 borders, 2 shadows)
  
  Patterns:
    Button: 36px h, 12px 16px pad, 6px radius
    Card: 1px border, 16px pad
  
  Create .interface-design/system.md with these? (y/n/customize)
  ```
  
  ## Implementation
  
  1. Glob for UI files
  2. Parse for repeated values
  3. Identify common patterns
  4. Suggest system based on frequency
  5. Offer to create system.md
  6. Let user customize before saving
  

• .claude-plugin/marketplace.jsonmarketplace
  Show content (934 bytes)

  {
    "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
    "name": "interface-design",
    "metadata": {
      "description": "Design engineering for Claude Code. Build interfaces with craft, memory, and enforcement."
    },
    "owner": {
      "name": "Damola Akinleye",
      "url": "https://github.com/Dammyjay93"
    },
    "plugins": [
      {
        "name": "interface-design",
        "description": "Design engineering for Claude Code. Build interfaces with craft, memory, and enforcement. Maintains consistent design decisions across sessions.",
        "version": "2026.2.9.1212",
        "author": {
          "name": "Damola Akinleye",
          "url": "https://github.com/Dammyjay93"
        },
        "source": "./",
        "category": "design",
        "homepage": "https://github.com/Dammyjay93/interface-design",
        "tags": ["design", "design-system", "ui", "craft", "memory", "enforcement", "consistency", "tokens"]
      }
    ]
  }
  

README

# Add the marketplace
/plugin marketplace add Dammyjay93/interface-design

# Install the plugin
/plugin menu

git clone https://github.com/Dammyjay93/interface-design.git
cd interface-design
cp -r .claude/* ~/.claude/
cp -r .claude-plugin/* ~/.claude-plugin/

✓ Reads skill files and principles
✓ Loads .interface-design/system.md
✓ Applies established patterns
✓ States design choices before each component
✓ Offers to save new patterns

1. Reads skill files and principles
2. Assesses project context
3. Suggests direction, asks for confirmation
4. States design choices before each component
5. Builds with consistent principles
6. Offers to save system

You: "Build a user dashboard with metrics cards"

Claude:
This feels like a data-heavy dashboard — I'd suggest:
- Depth: Borders-only (clean, technical)
- Surfaces: Subtle elevation shifts
- Spacing: 8px base

Does this direction fit?

[You: y]

Depth: borders-only
Surfaces: 7% → 9% → 11% lightness scale
Borders: rgba(255,255,255,0.06)
Spacing: 8px base

[Builds dashboard with consistent depth, spacing, surfaces]

Want me to save these patterns to .interface-design/system.md?

[You: y]

✓ System saved

You: "Add a settings page"

Claude:
✓ Loaded system.md

Depth: borders-only
Surfaces: using established scale
Borders: rgba(255,255,255,0.06)
Spacing: 8px base

[Builds settings page matching existing system]

Want me to save any new patterns?

# Design System

## Direction
Personality: Precision & Density
Foundation: Cool (slate)
Depth: Borders-only

## Tokens
### Spacing
Base: 4px
Scale: 4, 8, 12, 16, 24, 32

### Colors
--foreground: slate-900
--secondary: slate-600
--accent: blue-600

## Patterns
### Button Primary
- Height: 36px
- Padding: 12px 16px
- Radius: 6px
- Usage: Primary actions

### Card Default
- Border: 0.5px solid
- Padding: 16px
- Radius: 8px

/interface-design:init           # Start building with design principles
/interface-design:status         # Show current system
/interface-design:audit <path>   # Check code against system
/interface-design:extract        # Extract patterns from existing code

# Uninstall old
rm -rf ~/.claude/skills/design-principles

# Install new plugin
/plugin marketplace add Dammyjay93/interface-design
/plugin menu