| name | designkit |
| description | Use when designing or refining UI โ launches a browser-based companion with Comment, Inspect, and Tune tools for hands-on design iteration with Claude. |
Design Companion
A browser-based design refinement tool. Launches a local server that renders prototypes and gives designers hands-on tools to annotate, inspect, and tune visual properties โ then sends structured feedback to Claude for the next iteration.
When to Use
- The user asks to design, prototype, or build a UI component, page, or layout
- The user wants to refine or polish an existing design
- The user says "let's brainstorm" about anything visual
- Any task where showing a visual in the browser would help
Checklist
- Start the Design Companion server
- Generate the prototype following authoring standards
- Tell the user the URL and what tools are available
- Wait for the user to comment, inspect, or tune โ then tell you to process
- Read the events file for their feedback
- Apply changes based on annotations and tune values
- Push the updated screen โ repeat until done
Starting the Server
skills/designkit/scripts/start-server.sh --project-dir /path/to/project
Returns JSON with screen_dir, state_dir, and url. Save all three.
Tell the user to open the URL. Remind them of the keyboard shortcuts:
- Ctrl+C โ Comment mode (click to annotate elements)
- Ctrl+I โ Inspect mode (hover to see computed properties)
- Ctrl+T โ Tune mode (click to open live adjustment panel)
- Ctrl+A โ View staged changes
- Cmd+Z / Cmd+Shift+Z โ Undo/redo tune adjustments
- Shift+Cmd+Enter โ Send changes to Claude
- Esc โ Deselect tool / close panels
Generating Prototypes
Write HTML files to screen_dir. The server serves the newest file by modification time.
Content fragments (no <!DOCTYPE or <html>) are automatically wrapped in the companion frame template. Use for simple mockups.
Full documents are extracted โ their <style> and <body> content are pulled into the frame. The companion chrome (toolbar, menus) always appears. Use for complete page designs.
Authoring Standards
Every prototype MUST follow these rules:
-
Use CSS classes, not inline styles. Elements need semantic classes like .metric-card, .nav-link, .chart-section. The Tune panel's "Apply to all matching" finds siblings by class. Inline styles make every element unique and break this.
-
Use CSS custom properties (tokens) for design values. The Tune panel detects tokens and adjusts them on :root so changes cascade globally. Hardcoded values only affect one element.
-
Semantic class names. Classes describe what the element IS (.metric-card) not what it looks like (.p-4.bg-white). This makes annotation selectors meaningful.
Anti-Slop Rules
These are the most common tells of AI-generated UI. Avoid all of them:
-
No emoji icons. Never use ๐ ๐ ๐ or any emoji as UI icons. Use Lucide icons instead. Include this in the <head>:
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/lucide-static@latest/font/lucide.min.css">
Then use: <i class="lucide-chart-bar"></i>, <i class="lucide-search"></i>, etc.
-
Tight page headers. Don't waste 1/3 of the screen on a page title with massive padding. The page heading, action buttons, and any breadcrumbs should sit in a compact row with minimal vertical padding. padding: 0.75rem 0 max on the header row.
-
No orphaned whitespace. Every section should feel intentionally spaced. If there's a gap between a heading and content, or between the nav and the page body, it should be a deliberate rhythm (e.g. --space-md everywhere), not random large gaps.
-
Body text at 16px (1rem). Use --font-base: 1rem for body/table content. Reserve --font-sm: 0.875rem for secondary labels and metadata. Never set --font-base below 0.875rem.
-
Consistent text hierarchy. Navigation text, body text, and metadata should each have a clearly distinct size. Don't put tiny 11px text next to 16px text โ it looks accidental. Use the token scale: --font-xs for labels, --font-sm for secondary, --font-base for body, --font-lg for headings.
-
Dense layouts earn their density. If you're building a table or dashboard, make it genuinely information-dense โ not just a few items with lots of padding. Either fill the space with useful content or tighten the layout to fit its content.
Token block template โ include at the top of every prototype's <style>:
:root {
--color-primary: #4f46e5;
--color-primary-hover: #4338ca;
--color-bg: #f4f5f7;
--color-surface: #ffffff;
--color-border: #e5e7eb;
--color-text: #1a1a2e;
--color-text-secondary: #6b7280;
--color-text-tertiary: #9ca3af;
--color-success: #059669;
--color-warning: #d97706;
--color-danger: #dc2626;
--space-xs: 0.25rem;
--space-sm: 0.5rem;
--space-md: 1rem;
--space-lg: 1.5rem;
--space-xl: 2rem;
--font-xs: 0.75rem;
--font-sm: 0.875rem;
--font-base: 1rem;
--font-lg: 1.25rem;
--font-xl: 1.5rem;
--radius-sm: 6px;
--radius-md: 10px;
--shadow-sm: 0 1px 3px rgba(0,0,0,0.08);
--shadow-md: 0 4px 12px rgba(0,0,0,0.08);
}
Adjust token values to match the design direction. The token names should stay consistent so the Tune panel can find and adjust them.
Example โ correct:
<style>
:root { --space-md: 1rem; --radius-md: 10px; --color-surface: #fff; }
.metric-card {
padding: var(--space-md);
border-radius: var(--radius-md);
background: var(--color-surface);
}
</style>
<div class="metric-card">
<h3 class="metric-label">Revenue</h3>
<p class="metric-value">$48,250</p>
</div>
Example โ wrong (breaks tools):
<div style="padding: 1rem; border-radius: 10px; background: #fff;">
<h3 style="font-size: 0.7rem;">Revenue</h3>
<p style="font-size: 1.75rem;">$48,250</p>
</div>
File Naming
- Use semantic names:
dashboard.html, client-detail.html, settings-page.html
- Never reuse filenames โ each screen must be a new file
- For iterations:
dashboard-v2.html, dashboard-v3.html
- Use the Write tool โ never cat/heredoc
Reading Designer Feedback
After the user sends changes (via the Send button or Shift+Cmd+Enter), read the events file:
$STATE_DIR/events
The file contains JSONL โ one JSON object per line. Two types:
Comment annotations
{"type":"annotation","id":"ann-123","selector":".metric-card:nth-of-type(2) > .metric-value","tag":"p","text":"$48,250","note":"too large, try 1.5rem","status":"new","timestamp":1749000001}
selector โ CSS path to the element from #claude-content
tag + text โ human-readable element identity
note โ the designer's feedback
Tune changes
{"type":"tune","selector":".metric-card","tag":"div","text":"Revenue...","changes":{"padding":"12px","borderRadius":"8px"},"tokenChanges":{"--space-md":"0.75rem","--radius-md":"8px"},"timestamp":1749000002}
changes โ inline style changes applied to the element
tokenChanges โ CSS custom property changes applied to :root (these cascade globally)
Processing feedback:
- Read each line of the events file
- For annotations: find the element by selector, apply the designer's note as a targeted change
- For tune changes: apply
tokenChanges to the :root token block, apply changes as inline overrides where needed
- Write the updated HTML as a new file (e.g.,
dashboard-v2.html)
The Iteration Loop
- Write HTML to
screen_dir following authoring standards
- Tell the user: "Design is up at [URL]. Use the tools to review โ Ctrl+C for comments, Ctrl+T to tune values. Click Send when ready."
- User reviews, annotates, tunes, sends
- Read
$STATE_DIR/events
- Apply changes, write new HTML file
- Repeat until the user is satisfied
Each iteration is a clean slate. The events file is cleared when a new screen is pushed. Don't persist annotation state across iterations.
Stopping the Server
skills/designkit/scripts/stop-server.sh $SESSION_DIR
Mockup files persist in .designkit/sessions/ under the project directory for later reference.
Key Principles
- The designer drives. You generate, they refine. Don't skip the feedback loop.
- Tokens over hardcoded values. Always. The Tune panel's power comes from tokens.
- Classes over inline styles. Always. "Apply to all" depends on it.
- One screen at a time. Focus on refining one surface, not multi-page flows.
- Simple lifecycle. Fresh comments each round. No state management across iterations.
- Don't guess what changed. Read the events file. The designer's annotations are precise.