// You MUST use this before any creative or design work — building features, creating components, designing interfaces, modifying user-facing behaviour. Explores intent, constraints, users, and context before any design decisions are made
MUST run before any other Designpowers skill — shows welcome, checks taste profile, and routes to the correct first skill. Triggers on ANY design-related message. No other Designpowers skill may run until the welcome sequence has completed
Use when starting a new project or when taste decisions are made — accumulates the user's aesthetic preferences, recurring patterns, and design instincts across projects so each new project starts with what the system already knows about their taste
Use when any Designpowers agent starts work or completes work — maintains the shared design state file that all agents read from and write to. Invoke to initialise, read, or update the living design state document
Use when setting design direction — establishing principles, competitive positioning, experience mapping, or aligning stakeholders on what the design should achieve and why
Use when calibrating aesthetic direction — capturing design references, quality benchmarks, and the subjective qualities that make a design feel elevated. Invoked between strategy and design to give agents a shared sense of what "good" looks and feels like for this project
Use after the fix round to validate the design by walking through key tasks as each persona — simulating how Jordan (low-vision), Priya (non-native speaker), Marcus (motor impairment), or any project persona would actually experience the interface. Catches the issues that code review misses because they only surface in the act of using
| name | design-discovery |
| description | You MUST use this before any creative or design work — building features, creating components, designing interfaces, modifying user-facing behaviour. Explores intent, constraints, users, and context before any design decisions are made |
Discovery is where design begins. Before pixels, before wireframes, before any visual decisions — understand the problem. This skill ensures you never design the wrong thing well.
BEFORE running discovery, check whether the Designpowers welcome sequence has been shown this session. If the user has not yet seen the welcome (the bird, the greeting, and the walkthrough offer), you MUST invoke the using-designpowers skill FIRST and complete the welcome sequence before returning here. The bird must appear before any work begins. No exceptions.
DO NOT proceed to any design, UI, or implementation work until discovery is complete and the user has approved the design brief.
When the user says "proof of concept", "POC", "quick", "small", or the task is clearly exploratory:
"Quick version: what's the problem, who's it for, and what does success feel like? If you've got a design system or any references you love, throw those in too."
design-state.md in the project root immediately after brief approvalQuick discovery should take one user message of answers, not three. But the question should still feel like a person asking, not a form.
When the task is a full product, involves multiple stakeholders, or the user explicitly wants depth — use the full process below.
Before asking questions, gather what already exists:
Have a conversation, not an interrogation. The goal is to understand what the user wants to build and why — but the tone should feel like two people talking, not a form being filled out.
Start with an open invitation, not a structured question:
"Tell me about what you're building. What's the story behind it?"
Let the user talk. Listen for the answers to these questions in what they say, and only ask follow-ups for what's missing:
Ask follow-ups ONE AT A TIME. Don't list all missing items at once. Pick the most important gap, ask about it conversationally, and repeat. Frame questions around what they've already told you:
Weave in taste seeds naturally. Don't make these a separate section — fold them into the conversation when the moment feels right:
These are lightweight prompts, not the full taste calibration — that comes later via design-taste. But getting the user thinking about feel early means they arrive at taste calibration with sharper instincts. If they share a design system here, note it in the brief for the taste skill to pick up.
Acknowledge what they tell you. Before asking the next question, briefly reflect back what you heard. This shows you're listening and gives the user a chance to correct misunderstandings early:
"So this is about reducing no-shows for a small clinic — the receptionist is spending half their day on reminder calls. Got it. Who else is affected by this beyond the receptionist?"
For every design task, explicitly consider:
This is not a checklist to rush through. These are real people who will use what you build.
Present 2-3 design approaches with clear trade-offs:
For each approach:
Once the user has chosen a direction, write a design brief:
# Design Brief: [Feature/Component Name]
## Problem Statement
[What problem are we solving, for whom, in what context]
## Users
[Who this serves — including ability spectrum considerations]
## Design Direction
[The chosen approach and why]
## Constraints
[Technical, timeline, brand, accessibility, regulatory]
## Existing Design System
[Path to design system, style guide, or component library — or "None"]
## Taste Direction (Early Signal)
[Any references, feelings, or aesthetic preferences the user shared during discovery. This seeds the full taste calibration later.]
## Success Criteria
[How we will know this works]
## Out of Scope
[What we are explicitly NOT doing]
Save to: docs/designpowers/briefs/YYYY-MM-DD-<topic>.md
Present the brief to the user section by section — not all at once. Get approval on each section before moving to the next. The user must explicitly approve the complete brief before any design work begins.
This step is mandatory. Do not skip it.
Immediately after brief approval, create design-state.md in the project root with:
This file is the shared context every agent reads. If it does not exist, the pipeline cannot run.
After approval and design state creation, invoke the appropriate next skill:
research-planningdesign-strategy or writing-design-plansusing-designpowers (auto-triggered on any design task)research-planning, design-strategy, or writing-design-plansui-composition, interaction-design, or any implementation skill| Flag | Response |
|---|---|
| "Just make it look like this reference" | References inform — they do not replace discovery. Ask what about the reference works and why |
| "We already know what we want" | Great. Then discovery will be fast. But still do it — assumptions are where bad design hides |
| "This is just a small change" | Small changes to interfaces affect real people. Discovery scales to the task — it does not get skipped |