From designpowers
Guides pre-design discovery for features, components, or UI: explores problem, users, intent, constraints. Quick mode for POCs; full process for products.
npx claudepluginhub owl-listener/designpowers --plugin designpowersThis skill uses the workspace's default tool permissions.
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.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
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 |