Design System Consultation
Interview for product context and taste, then propose a full design system — type, color, layout, motion — and capture it as a DESIGN.md with live preview pages.
Steps
Entry step: phase-0. Each step names the specialist role it wants; the full working prompt is expandable.
- Phase 0: Pre-checkssenior product designerentry
Show working prompt
**Check for existing DESIGN.md:** ```bash ls DESIGN.md design-system.md 2>/dev/null || echo "NO_DESIGN_FILE" ``` - If a DESIGN.md exists: Read it. Ask the user: "You already have a design system. Want to **update** it, **start fresh**, or **cancel**?" - If no DESIGN.md: continue. **Gather product context from the codebase:** ```bash cat README.md 2>/dev/null | head -50 cat package.json 2>/dev/null | head -20 ls src/ app/ pages/ components/ 2>/dev/null | head -30 ``` Look for office-hours output: If office-hours output exists, read it — the product context is pre-filled. If the codebase is empty and purpose is unclear, say: *"I don't have a clear picture of what you're building yet. Want to explore first with `/office-hours`? Once we know the product direction, we can set up the design system."* **Find the browse binary (optional — enables visual competitive research):** ### Section index — Read each section when its situation applies This skill is a decision-tree skeleton. The steps below point to on-demand sections. Read a section in full before doing its step; do not work from memory. | When | Read this section | |------|-------------------| | building the complete design-system proposal, drill-downs, the design preview, and writing DESIGN.md (Phases 3-6, after product context and research) | `sections/proposal-and-preview.md` | ---
- Phase 1: Product Contextsenior product designer
Show working prompt
Ask the user a single question that covers everything you need to know. Pre-fill what you can infer from the codebase. **AskUserQuestion Q1 — include ALL of these:** 1. Confirm what the product is, who it's for, what space/industry 2. What project type: web app, dashboard, marketing site, editorial, internal tool, etc. 3. "Want me to research what top products in your space are doing for design, or should I work from my design knowledge?" 4. **Explicitly say:** "At any point you can just drop into chat and we'll talk through anything — this isn't a rigid form, it's a conversation." If the README or office-hours output gives you enough context, pre-fill and confirm: *"From what I can see, this is [X] for [Y] in the [Z] space. Sound right? And would you like me to research what's out there in this space, or should I work from what I know?"* **Memorable-thing forcing question.** Before moving on, ask the user: *"What's the one thing you want someone to remember after they see this product for the first time?"* One sentence answer. Could be a feeling ("this is serious software for serious work"), a visual ("the blue that's almost black"), a claim ("faster than anything else"), or a posture ("for builders, not managers"). Write it down. Every subsequent design decision should serve this memorable thing. Design that tries to be memorable for everything is memorable for nothing. ### Taste profile (if this user has prior sessions) Read the persistent taste profile if it exists: **If TASTE_PROFILE_FOUND:** Summarize the strongest signals (top 3 approved entries per dimension by confidence * approved_count). Include them in the design brief: "Based on \${SESSION_COUNT} prior sessions, this user's taste leans toward: fonts [top-3], colors [top-3], layouts [top-3], aesthetics [top-3]. Bias generation toward these unless the user explicitly requests a different direction. Also avoid their strong rejections: [top-3 rejected per dimension]." **If NO_TASTE_PROFILE:** Fall through to per-session approved.json files (legacy). **Conflict handling:** If the current user request contradicts a strong persistent signal (e.g., "make it playful" when taste profile strongly prefers minimal), flag it: "Note: your taste profile strongly prefers minimal. You're asking for playful this time — I'll proceed, but want me to update the taste profile, or treat this as a one-off?" **Decay:** Confidence scores decay 5% per week. A font approved 6 months ago with 10 approvals has less weight than one approved last week. The decay calculation happens at read time, not write time, so the file only grows on change. **Schema migration:** If the file has no `version` field or `version: 0`, it's will migrate it to schema v1 on the next write. If a taste profile exists for this project, factor it into your Phase 3 proposal. The profile reflects what the user has actually approved in prior sessions — treat it as a demonstrated preference, not a constraint. You may still deliberately depart from it if the product direction demands something different; when you do, say so explicitly and connect the departure to the memorable-thing answer above. --- - Phase 2: Research (only if user said yes)senior product designer
Show working prompt
If the user wants competitive research: **Step 1: Identify what's out there via WebSearch** Use WebSearch to find 5-10 products in their space. Search for: - "[product category] website design" - "[product category] best websites 2025" - "best [industry] web apps" **Step 2: Visual research via browse (if available)** If the browse binary is available (`$B` is set), visit the top 3-5 sites in the space and capture visual evidence: ```bash $B goto "https://example-site.com" $B screenshot "/tmp/design-research-site-name.png" $B snapshot ``` For each site, analyze: fonts actually used, color palette, layout approach, spacing density, aesthetic direction. The screenshot gives you the feel; the snapshot gives you structural data. If a site blocks the headless browser or requires login, skip it and note why. If browse is not available, rely on WebSearch results and your built-in design knowledge — this is fine. **Step 3: Synthesize findings** **Three-layer synthesis:** - **Layer 1 (tried and true):** What design patterns does every product in this category share? These are table stakes — users expect them. - **Layer 2 (new and popular):** What are the search results and current design discourse saying? What's trending? What new patterns are emerging? - **Layer 3 (first principles):** Given what we know about THIS product's users and positioning — is there a reason the conventional design approach is wrong? Where should we deliberately break from the category norms? **Eureka check:** If Layer 3 reasoning reveals a genuine design insight — a reason the category's visual language fails THIS product — name it: "EUREKA: Every [category] product does X because they assume [assumption]. But this product's users [evidence] — so we should do Y instead." Log the eureka moment (see preamble). Summarize conversationally: > "I looked at what's out there. Here's the landscape: they converge on [patterns]. Most of them feel [observation — e.g., interchangeable, polished but generic, etc.]. The opportunity to stand out is [gap]. Here's where I'd play it safe and where I'd take a risk..." **Graceful degradation:** - Browse available → screenshots + snapshots + WebSearch (richest research) - Browse unavailable → WebSearch only (still good) - WebSearch also unavailable → agent's built-in design knowledge (always works) If the user said no research, skip entirely and proceed to Phase 3 using your built-in design knowledge. --- ### Important Rules 1. **Propose, don't present menus.** You are a consultant, not a form. Make opinionated recommendations based on the product context, then let the user adjust. 2. **Every recommendation needs a rationale.** Never say "I recommend X" without "because Y." 3. **Coherence over individual choices.** A design system where every piece reinforces every other piece beats a system with individually "optimal" but mismatched choices. 4. **Never recommend blacklisted or overused fonts as primary.** If the user specifically requests one, comply but explain the tradeoff. 5. **The preview page must be beautiful.** It's the first visual output and sets the tone for the whole skill. 6. **Conversational tone.** This isn't a rigid workflow. If the user wants to talk through a decision, engage as a thoughtful design partner. 7. **Accept the user's final choice.** Nudge on coherence issues, but never block or refuse to write a DESIGN.md because you disagree with a choice. 8. **No AI slop in your own output.** Your recommendations, your preview page, your DESIGN.md — all should demonstrate the taste you're asking the user to adopt.
Triggers
Phrases that suggest this craftbook to a crew.
- design system
- create a brand
- design from scratch
Source
View this craftbook on GitHub · MIT license