Client Prototype

Use this when pairing with a client and you need a prototype that uses the client company's brand identity instead of the default brand. This skill handles brand discovery first, then builds the prototype.

Process

Phase 1: Brand discovery

Ask the user:

How should I get the client's brand information? A) I'll tell you — I'll provide the colors, fonts, and style details B) Pull from Figma — extract brand tokens from a client Figma file C) Pull from their website — extract colors and fonts from the client's site

Path A: Interactive brand gathering

Walk through the questionnaire at reference/brand-gathering-template.md. At minimum, gather:

1. Client name
2. Primary color (hex) — main brand color for CTAs, headers
3. Secondary color (hex) — supporting accent
4. Background color (hex) — page/card background (default: #FFFFFF)
5. Text color (hex) — primary body text (default: #1A1A1A)
6. Heading font — font family for headings (default: system sans-serif)
7. Body font — font family for body text (default: system sans-serif)
8. Logo — file path or URL (optional)
9. Style notes — rounded vs. sharp corners, dense vs. spacious, any other visual preferences

Store the gathered info as a Client Brand Token block (see format below).

Path B: Figma brand extraction

1. Ask for the client's Figma file URL
2. Extract the fileKey and nodeId from the URL
3. Use Figma MCP tools:
   • get_variable_defs (with the fileKey and nodeId) — extract design tokens (colors, spacing, typography)
   • get_design_context — understand component patterns and code
   • get_screenshot — capture visual reference for style matching
4. Parse the extracted variables into the Client Brand Token format
5. Confirm with the user before proceeding — show the extracted tokens and ask if they look right

Path C: Website brand extraction

1. Ask for the client's website URL
2. Use WebFetch to get the page content
3. Look for:
   • CSS custom properties and color definitions
   • Font imports (Google Fonts, Adobe Fonts, @font-face declarations)
   • Meta theme-color tags
   • Dominant colors in the stylesheet
4. Parse into the Client Brand Token format
5. Confirm with the user — website extraction is approximate, so verify the values

Client Brand Token format

After gathering brand info from any source, structure it as:

## Client Brand Tokens: (Client Name)

### Colors
| Role            | Hex       |
|----------------|-----------|
| Primary         | (hex)     |
| Secondary       | (hex)     |
| Background      | (hex)     |
| Surface         | (hex)     |
| Text            | (hex)     |
| Text Secondary  | (hex)     |
| Accent          | (hex)     |
| Border          | (hex)     |

### Typography
| Role     | Font Family | Weight | Notes      |
|----------|-------------|--------|------------|
| Heading  | (name)      | (wt)   | (style)    |
| Body     | (name)      | (wt)   | (style)    |

### Style notes
- Corner radius: (sharp / slightly rounded / rounded / pill)
- Spacing density: (compact / default / spacious)
- Other: (any additional style notes)

Fallback behavior: If the user cannot provide complete brand info, use these sensible defaults and clearly mark which tokens are assumed vs. confirmed:

• Background: #FFFFFF
• Surface: #F8F9FA
• Text: #1A1A1A
• Text Secondary: #6B7280
• Border: #E5E7EB
• Fonts: system sans-serif (-apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif)
• Corner radius: 8px
• Spacing: default

Phase 2: Prototype generation

Consider the builder: If the client team includes non-technical stakeholders who want to iterate on prototypes independently, consider recommending a prompt-to-app tool (Lovable, v0, bolt.new) instead of or alongside this skill. Those tools let PMs and designers build and iterate without developer pairing. Use /ai-prototype-guide to help them choose the right one. This skill is best when Kate is pairing directly and needs client branding applied to an HTML prototype.

Ask the user:

Which prototype approach do you want? A) HTML/CSS prototype — interactive, runs in browser with live preview B) Figma design spec — design specifications using client brand tokens

HTML prototype

Follow the same approach as /artium-prototype (HTML path), but:

1. Replace the Tailwind config colors with the client brand tokens instead of the default tokens
2. Replace font imports with the client's fonts (add Google Fonts link if applicable)
3. Replace the .apex-heading style with the client's heading style (or omit if not applicable)
4. Use the client's color roles for components: primary for CTAs, secondary for accents, etc.

Generate ./prototypes/(client-name)-(prototype-name)/index.html.

Figma design spec

Follow the same approach as /artium-prototype (Figma path), but use client brand tokens instead of the default tokens for all specifications.

Accessible component checklist

After generating any prototype (HTML or Figma spec), verify:

• Semantic HTML -- buttons use <button>, links use <a>, navigation uses <nav>, main content uses <main>
• Keyboard navigation -- all interactive elements reachable via tab, activatable via Enter/Space
• Focus indicators -- visible focus styles on all interactive elements (don't remove browser defaults without replacing them)
• ARIA labels -- custom components have accessible names (aria-label or aria-labelledby). Icon-only buttons have text alternatives.
• Color contrast -- text meets 4.5:1 ratio, UI components meet 3:1 ratio against background
• Form labels -- all inputs have visible, associated labels (not just placeholders)
• Skip navigation -- if the prototype has repeated navigation, include a skip link to main content
• Heading hierarchy -- h1-h6 levels follow logical order without skipping

This checklist applies to communication prototypes, not production code. The goal is ensuring the prototype demonstrates accessible patterns the engineering team should implement.

Output location

All client prototypes go in ./prototypes/(client-name)-(prototype-name)/. Create this directory if it doesn't exist.