// 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
| name | design-taste |
| description | 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 |
Process discipline produces correct design. Taste produces design people love. This skill captures the subjective, aesthetic dimension that no checklist can replace — the difference between a design that works and one that sings.
BEFORE calibrating taste, 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.
The Designpowers workflow verifies that designs are:
But none of that answers: Is it beautiful? Does it feel right? Is it elevated?
Taste is the gap between compliance and craft. This skill gives agents a shared vocabulary and reference point for the aesthetic quality the project demands.
This step is a conversation, not a form. Actively prompt the user — don't wait for them to volunteer. Most people have strong taste but haven't been asked the right questions. Your job is to draw it out.
Before asking subjective questions, check what already exists:
If a design system exists, read it first. Extract the taste signals already embedded in it:
Document what the design system already tells you about taste before asking for more. The user shouldn't have to re-articulate what their system already expresses.
After reviewing any existing system, prompt the user for their subjective direction. Ask these directly — do not skip this step. The user's gut feelings and personal instincts are the most valuable input. Meet them where they are — not everyone speaks in design terms.
Prompt with these questions (adapt to context):
Not every question is needed. Read the room. If the user has strong visual instincts, lean on references. If they think in feelings, lean on emotional targets. If they have anti-references, those are often more revealing than positive ones.
Important: The user's subjective thoughts override what's in the design system. If the system says "sharp corners" but the user says "I want it to feel warmer," the taste profile should reflect the user's intent — and note the tension with the existing system as something to reconcile.
For each design reference the user provides, extract the specific qualities that make it work:
## Reference Analysis: [Name/URL]
**What makes this feel good:**
- [Specific quality] — e.g., "generous whitespace creates breathing room"
- [Specific quality] — e.g., "typography has a single accent weight, never competes"
- [Specific quality] — e.g., "colour palette is 90% neutral, 10% vibrant — the accent hits harder because it's rare"
**Craft details worth noting:**
- [Detail] — e.g., "borders are 1px at 8% opacity, not solid lines"
- [Detail] — e.g., "shadows use 2 layers: a tight sharp shadow + a soft ambient"
- [Detail] — e.g., "hover states use scale(1.02), not colour change"
**What to borrow (principle, not pixel):**
- [Transferable pattern] — e.g., "restraint in colour — let one accent do the work"
- [Transferable pattern] — e.g., "consistent radius vocabulary: 4px for inputs, 8px for cards, 16px for modals"
Synthesise the references, emotional targets, and anti-references into a taste profile. This is the document that agents use when making aesthetic decisions.
# Taste Profile: [Project Name]
## Existing Design System
[If one exists: what it already tells us about taste — palette philosophy, spacing density, personality signals from tokens/components. If none: "No existing design system — building taste from scratch."]
### Taste Signals from the System
- Colour philosophy: [e.g., "restrained neutral palette with a single blue accent"]
- Density: [e.g., "generous spacing — the system breathes"]
- Personality: [e.g., "rounded corners (8px default) suggest approachability"]
- Typography voice: [e.g., "Inter for UI, serif for marketing — functional and warm"]
### Where the User Wants to Evolve
[What the user wants to change, extend, or push further from the existing system]
## Emotional Target
[2-3 sentences: what this should feel like to use]
## Aesthetic Principles
[3-5 principles specific to the visual/emotional quality, not functional design]
1. **[Principle name]** — [What it means]
_Test: [How to evaluate whether a design decision follows this]_
2. **[Principle name]** — [What it means]
_Test: [How to evaluate]_
## Quality Level
[Prototype / Production / Flagship]
[What this means in practice — e.g., "flagship: every pixel intentional, micro-interactions polished, typography refined to the point of invisibility"]
## References
| Reference | What to borrow | What to avoid |
|-----------|---------------|---------------|
| [Name] | [Specific qualities] | [What not to copy] |
## Anti-References
| Anti-reference | What makes it wrong for us |
|----------------|---------------------------|
| [Name] | [Specific qualities to avoid] |
## Craft Standards
[Specific details that define the quality bar]
- Shadows: [approach]
- Borders: [approach]
- Radius: [vocabulary]
- Colour usage: [restraint rules]
- Typography pairing: [rules]
- Whitespace: [philosophy — generous/tight/balanced]
- Animation: [personality — snappy/fluid/springy/minimal]
## Personality
[If the product were a person: how they'd dress, speak, move]
Save to: docs/designpowers/taste/YYYY-MM-DD-<project>-taste.md
After the taste profile is created, update design-state.md:
## Taste Profile
- **Emotional target:** [2-3 words]
- **Quality level:** [Prototype / Production / Flagship]
- **Key references:** [names]
- **Aesthetic principles:** [list]
- **Taste document:** [path]
Present the taste profile and ask: "Does this capture what you're going for?"
The user's taste overrides everything. If they say "I want it to feel like Linear but warmer," that's the direction — even if the references suggest otherwise.
Once the taste profile exists, it becomes a reference document for the entire workflow:
| Agent | How they use taste |
|---|---|
| design-lead | Makes aesthetic decisions that serve the emotional target and craft standards. References the taste profile alongside design principles |
| motion-designer | Matches animation personality to the taste profile (snappy vs. fluid vs. springy). Easing curves should feel like the product's personality |
| content-writer | Matches voice warmth/formality to the product personality. A "quiet authority" product doesn't use exclamation marks |
| design-builder | Implements craft details at the specified quality level. A flagship build polishes shadows, transitions, and spacing to the pixel |
| design-critic | Evaluates craft quality against the taste profile, not just compliance. "This meets the brief but falls below the quality bar" is a valid critique |
| accessibility-reviewer | Ensures taste decisions don't compromise access. Thin, elegant text is a taste choice that might fail contrast. Flag the tension, don't just override |
Good taste is specific, consistent, and defensible. It is not "I like blue" — it is "blue at 12% opacity as a background tint creates the calm, clinical feel our medical app needs, referencing the quiet confidence of the references we chose."
Every taste decision should connect back to:
Taste that excludes people is not good taste. If a thin, delicate typeface creates the right mood but fails readability for low-vision users, find a typeface that does both. The constraint makes the design better, not worse.
| Flag | Response |
|---|---|
| No references at all | Push gently. Even "I like how Apple does things" gives direction |
| References that contradict each other | This is fine — extract what's common, flag what conflicts, ask the user to resolve |
| Taste profile that violates accessibility | Find the version that serves both. Thin borders can be elegant AND meet contrast ratios. It's harder, but it's the job |
| "Just make it look good" | Not enough. Probe deeper: "Good like Stripe? Good like Notion? Good like a luxury hotel?" — taste needs specifics |
| Quality level doesn't match timeline | Flag the tension. Flagship quality takes time. If the timeline says prototype, the taste profile should reflect achievable craft |
design-strategy (once principles exist, calibrate taste)ui-composition, interaction-design, motion-choreographydesign-lead, motion-designer, content-writer, design-builder, design-criticMUST 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
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
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 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