Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 67 additions & 0 deletions .cursor/rules/interface-design-audit.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
---
description: Use when user asks to audit or check their code against the design system for spacing, depth, color, and pattern violations.
globs:
alwaysApply: false
---

# Design System Audit

Check existing code against your design system.

## Usage

User says "audit", "audit <path>", or "check against system".

## 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 `.interface-design/system.md`
2. Parse system rules
3. Read target files (tsx, jsx, css, scss)
4. Compare against rules
5. Report violations with suggestions
69 changes: 69 additions & 0 deletions .cursor/rules/interface-design-critique.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
---
description: Use when user asks to critique, review, or refine their UI build. Evaluates craft quality and rebuilds defaulted areas.
globs:
alwaysApply: false
---

# 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 workflow 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.
92 changes: 92 additions & 0 deletions .cursor/rules/interface-design-examples.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
---
description: Real-world craft examples showing how subtle layering translates to design decisions for dashboards, sidebars, dropdowns, and form controls.
globs:
alwaysApply: false
---

# Craft in Action

This shows how the subtle layering principle translates to real decisions. Learn the thinking, not the code. Your values will differ — the approach won't.

---

## The Subtle Layering Mindset

Before looking at any example, internalize this: **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. When you look at Supabase, you don't think "good surface elevation." You just know what's above what. The craft is invisible — that's how you know it's working.

---

## Example: Dashboard with Sidebar and Dropdown

### The Surface Decisions

**Why so subtle?** Each elevation 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. This is the Vercel/Supabase way — whisper-quiet shifts that you feel rather than see.

**What NOT to do:** Don't make dramatic jumps between elevations. That's jarring. Don't use different hues for different levels. Keep the same hue, shift only lightness.

### The Border Decisions

**Why rgba, not solid colors?** Low opacity borders blend with their background. A low-opacity white border on a dark surface is barely there — it defines the edge without demanding attention. Solid hex borders look harsh in comparison.

**The test:** Look at your interface from arm's length. If borders are the first thing you notice, reduce opacity. If you can't find where regions end, increase slightly.

### The Sidebar Decision

**Why same background as canvas, not different?**

Many dashboards make the sidebar a different color. This fragments the visual space — now you have "sidebar world" and "content world."

Better: Same background, subtle border separation. The sidebar is part of the app, not a separate region. Vercel does this. Supabase does this. The border is enough.

### The Dropdown Decision

**Why surface-200, not surface-100?**

The dropdown floats above the card it emerged from. If both were surface-100, the dropdown would blend into the card — you'd lose the sense of layering. Surface-200 is just light enough to feel "above" without being dramatically different.

**Why border-overlay instead of border-default?**

Overlays (dropdowns, popovers) often need slightly more definition because they're floating in space. A touch more border opacity helps them feel contained without being harsh.

---

## Example: Form Controls

### Input Background Decision

**Why darker, not lighter?**

Inputs are "inset" — they receive content, they don't project it. A slightly darker background signals "type here" without needing heavy borders. This is the alternative-background principle.

### Focus State Decision

**Why subtle focus states?**

Focus needs to be visible, but you don't need a glowing ring or dramatic color. A noticeable increase in border opacity is enough for a clear state change. Subtle-but-noticeable — the same principle as surfaces.

---

## Adapt to Context

Your product might need:
- Warmer hues (slight yellow/orange tint)
- Cooler hues (blue-gray base)
- Different lightness progression
- Light mode (principles invert — higher elevation = shadow, not lightness)

**The principle is constant:** barely different, still distinguishable. The values adapt to context.

---

## The Craft Check

Apply the squint test to your work:

1. Blur your eyes or step back
2. Can you still perceive hierarchy?
3. Is anything jumping out at you?
4. Can you tell where regions begin and end?

If hierarchy is visible and nothing is harsh — the subtle layering is working.
78 changes: 78 additions & 0 deletions .cursor/rules/interface-design-extract.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
---
description: Use when user asks to extract design patterns from existing code to create or update a system.md file.
globs:
alwaysApply: false
---

# Extract Design Patterns

Extract design patterns from existing code to create a system.

## Usage

User says "extract", "extract patterns", or "extract <path>".

## 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 the user:**
```
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. Search for UI files
2. Parse for repeated values
3. Identify common patterns
4. Suggest system based on frequency
5. Offer to create `.interface-design/system.md`
6. Let user customize before saving
73 changes: 73 additions & 0 deletions .cursor/rules/interface-design-init.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
description: Use when user asks to build, design, or create UI — dashboards, apps, tools, admin panels. Starts the craft-first design workflow.
globs:
alwaysApply: false
---

# Build UI with Craft

**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]"

[Ask: "Does that direction feel right?"]
```

## Flow

1. Check if `.interface-design/system.md` exists
2. **If exists**: Apply established patterns from system.md
3. **If not**: Assess context, suggest direction, get confirmation, build

## 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.
Loading