mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-12 14:16:28 +03:00
Add mandatory preparation to design-transformative commands
Commands now require context gathering before proceeding: - bolder: target audience, use-cases, brand personality - quieter: purpose, audience, what's working - colorize: brand colors, audience, domain appropriateness - animate: personality, performance budget, audience - delight: brand personality, emotional context, appropriateness - simplify: what's essential vs nice-to-have Each command now: 1. Gathers context from thread/codebase first 2. MUST ask user if inference confidence is medium or lower 3. MUST use frontend-design skill before proceeding 4. Has visual separator (---) as hard gate before design work This prevents AI slop by ensuring commands have proper context before making design decisions. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Paul Bakaus
co-authored by
Claude Opus 4.5
Claude Opus 4.5
parent
825d936f20
commit
020ac82748
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -28,6 +45,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -52,7 +71,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -29,6 +46,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -47,13 +66,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -36,6 +53,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -113,29 +132,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -179,7 +198,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -196,7 +215,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -28,6 +45,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -52,7 +71,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -29,6 +46,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -47,13 +66,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -36,6 +53,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -113,29 +132,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -179,7 +198,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -196,7 +215,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -28,6 +45,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -52,7 +71,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -29,6 +46,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -47,13 +66,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -36,6 +53,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -113,29 +132,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -179,7 +198,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -196,7 +215,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and STOP and call the AskUserQuestionTool to clarify. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST STOP and call the AskUserQuestionTool to clarify. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, STOP and call the AskUserQuestionTool to clarify.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -3,10 +3,27 @@ description: Review a feature and enhance it with purposeful animations, micro-i
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -24,6 +41,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -48,7 +67,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -3,10 +3,27 @@ description: Amplify safe or boring designs to make them more visually interesti
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -3,10 +3,27 @@ description: Add strategic color to features that are too monochromatic or lack
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -25,6 +42,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -43,13 +62,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -3,10 +3,27 @@ description: Add moments of joy, personality, and unexpected touches that make i
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -32,6 +49,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -109,29 +128,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -175,7 +194,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -192,7 +211,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -3,10 +3,27 @@ description: Tone down overly bold or visually aggressive designs. Reduces inten
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -25,6 +42,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -3,10 +3,27 @@ description: Strip designs to their essence by removing unnecessary complexity.
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -25,6 +42,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
Vendored
+22
-3
@@ -3,10 +3,27 @@ description: Review a feature and enhance it with purposeful animations, micro-i
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -24,6 +41,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -48,7 +67,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
Vendored
+19
-2
@@ -3,10 +3,27 @@ description: Amplify safe or boring designs to make them more visually interesti
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -3,10 +3,27 @@ description: Add strategic color to features that are too monochromatic or lack
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -25,6 +42,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -43,13 +62,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
Vendored
+35
-16
@@ -3,10 +3,27 @@ description: Add moments of joy, personality, and unexpected touches that make i
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -32,6 +49,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -109,29 +128,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -175,7 +194,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -192,7 +211,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
Vendored
+21
-2
@@ -3,10 +3,27 @@ description: Tone down overly bold or visually aggressive designs. Reduces inten
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -25,6 +42,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -3,10 +3,27 @@ description: Strip designs to their essence by removing unnecessary complexity.
|
||||
argument-hint: [TARGET=<value>]
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -25,6 +42,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -19,6 +36,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -43,7 +62,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -20,6 +37,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -38,13 +57,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -27,6 +44,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -104,29 +123,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -170,7 +189,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -187,7 +206,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -20,6 +37,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -20,6 +37,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -19,6 +36,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -43,7 +62,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -20,6 +37,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -38,13 +57,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -27,6 +44,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -104,29 +123,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -170,7 +189,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -187,7 +206,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -20,6 +37,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -1,7 +1,24 @@
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -20,6 +37,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -1,9 +1,26 @@
|
||||
description = "Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -21,6 +38,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -45,7 +64,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -1,9 +1,26 @@
|
||||
description = "Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -1,9 +1,26 @@
|
||||
description = "Add strategic color to features that are too monochromatic or lack visual interest. Makes interfaces more engaging and expressive."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -22,6 +39,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -40,13 +59,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -1,9 +1,26 @@
|
||||
description = "Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -29,6 +46,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -106,29 +125,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -172,7 +191,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -189,7 +208,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -1,9 +1,26 @@
|
||||
description = "Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -22,6 +39,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -1,9 +1,26 @@
|
||||
description = "Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -22,6 +39,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
+22
-3
@@ -1,9 +1,26 @@
|
||||
description = "Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -21,6 +38,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -45,7 +64,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
|
||||
+19
-2
@@ -1,9 +1,26 @@
|
||||
description = "Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
|
||||
+23
-4
@@ -1,9 +1,26 @@
|
||||
description = "Add strategic color to features that are too monochromatic or lack visual interest. Makes interfaces more engaging and expressive."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -22,6 +39,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -40,13 +59,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
|
||||
+35
-16
@@ -1,9 +1,26 @@
|
||||
description = "Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -29,6 +46,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -106,29 +125,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -172,7 +191,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -189,7 +208,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
|
||||
+21
-2
@@ -1,9 +1,26 @@
|
||||
description = "Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -22,6 +39,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
|
||||
+21
-2
@@ -1,9 +1,26 @@
|
||||
description = "Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean."
|
||||
prompt = """
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user directly to clarify what you cannot infer. whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user directly to clarify what you cannot infer. clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -22,6 +39,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone (playful vs serious, energetic vs calm), and performance constraints.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to inappropriate or excessive animation.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Animation Opportunities
|
||||
|
||||
Analyze where motion would improve the experience:
|
||||
@@ -28,6 +45,8 @@ Analyze where motion would improve the experience:
|
||||
- Who's the audience? (Motion-sensitive users? Power users who want speed?)
|
||||
- What matters most? (One hero animation vs many micro-interactions?)
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: Respect `prefers-reduced-motion`. Always provide non-animated alternatives for users who need them.
|
||||
|
||||
## Plan Animation Strategy
|
||||
@@ -52,7 +71,7 @@ Add motion systematically across these categories:
|
||||
- **Modal/drawer entry**: Smooth slide + fade, backdrop fade, focus management
|
||||
|
||||
### Micro-interactions
|
||||
- **Button feedback**:
|
||||
- **Button feedback**:
|
||||
- Hover: Subtle scale (1.02-1.05), color shift, shadow increase
|
||||
- Click: Quick scale down then up (0.95 → 1), ripple effect
|
||||
- Loading: Spinner or pulse state
|
||||
@@ -168,4 +187,3 @@ Test animations thoroughly:
|
||||
- **Adds value**: Makes interface clearer or more delightful
|
||||
|
||||
Remember: Motion should enhance understanding and provide feedback, not just add decoration. Animate with purpose, respect performance constraints, and always consider accessibility. Great animation is invisible - it just makes everything feel right.
|
||||
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too safe or boring:
|
||||
@@ -112,4 +129,3 @@ Ensure amplification maintains usability and coherence:
|
||||
**The test**: If you showed this to someone and said "AI made this bolder," would they believe you immediately? If yes, you've failed. Bold means distinctive, not "more AI effects."
|
||||
|
||||
Remember: Bold design is confident design. It takes risks, makes statements, and creates memorable experiences. But bold without strategy is just loud. Be intentional, be dramatic, be unforgettable.
|
||||
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and especially existing brand colors.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic AI slop colors.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Color Opportunity
|
||||
|
||||
Analyze the current state and identify opportunities:
|
||||
@@ -29,6 +46,8 @@ Analyze the current state and identify opportunities:
|
||||
- **Wayfinding**: Helping users navigate and understand structure
|
||||
- **Delight**: Moments of visual interest and personality
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.
|
||||
|
||||
## Plan Color Strategy
|
||||
@@ -47,13 +66,13 @@ Create a purposeful color introduction plan:
|
||||
Add color systematically across these dimensions:
|
||||
|
||||
### Semantic Color
|
||||
- **State indicators**:
|
||||
- **State indicators**:
|
||||
- Success: Green tones (emerald, forest, mint)
|
||||
- Error: Red/pink tones (rose, crimson, coral)
|
||||
- Warning: Orange/amber tones
|
||||
- Info: Blue tones (sky, ocean, indigo)
|
||||
- Neutral: Gray/slate for inactive states
|
||||
|
||||
|
||||
- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
|
||||
- **Progress indicators**: Colored bars, rings, or charts showing completion or health
|
||||
|
||||
@@ -136,4 +155,3 @@ Test that colorization improves the experience:
|
||||
- **Not overwhelming**: Is color balanced and purposeful?
|
||||
|
||||
Remember: Color is emotional and powerful. Use it to create warmth, guide attention, communicate meaning, and express personality. But restraint and strategy matter more than saturation and variety. Be colorful, but be intentional.
|
||||
|
||||
|
||||
+35
-17
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality (playful vs professional vs quirky vs elegant), and what's appropriate for the domain.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Delight that's wrong for the context is worse than no delight at all.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Delight Opportunities
|
||||
|
||||
Identify where delight would enhance (not distract from) the experience:
|
||||
@@ -36,6 +53,8 @@ Identify where delight would enhance (not distract from) the experience:
|
||||
- **Helpful surprises**: Anticipating needs before users ask (productivity tools)
|
||||
- **Sensory richness**: Satisfying sounds, smooth animations (creative tools)
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: Delight should enhance usability, never obscure it. If users notice the delight more than accomplishing their goal, you've gone too far.
|
||||
|
||||
## Delight Principles
|
||||
@@ -113,29 +132,29 @@ Add personality and joy through these methods:
|
||||
|
||||
**Playful error messages**:
|
||||
```
|
||||
❌ "Error 404"
|
||||
✅ "This page is playing hide and seek. (And winning)"
|
||||
"Error 404"
|
||||
"This page is playing hide and seek. (And winning)"
|
||||
|
||||
❌ "Connection failed"
|
||||
✅ "Looks like the internet took a coffee break. Want to retry?"
|
||||
"Connection failed"
|
||||
"Looks like the internet took a coffee break. Want to retry?"
|
||||
```
|
||||
|
||||
**Encouraging empty states**:
|
||||
```
|
||||
❌ "No projects"
|
||||
✅ "Your canvas awaits. Create something amazing."
|
||||
"No projects"
|
||||
"Your canvas awaits. Create something amazing."
|
||||
|
||||
❌ "No messages"
|
||||
✅ "Inbox zero! You're crushing it today."
|
||||
"No messages"
|
||||
"Inbox zero! You're crushing it today."
|
||||
```
|
||||
|
||||
**Playful labels & tooltips**:
|
||||
```
|
||||
❌ "Delete"
|
||||
✅ "Send to void" (for playful brand)
|
||||
"Delete"
|
||||
"Send to void" (for playful brand)
|
||||
|
||||
❌ "Help"
|
||||
✅ "Rescue me" (tooltip)
|
||||
"Help"
|
||||
"Rescue me" (tooltip)
|
||||
```
|
||||
|
||||
**IMPORTANT**: Match copy personality to brand. Banks shouldn't be wacky, but they can be warm.
|
||||
@@ -179,7 +198,7 @@ Add personality and joy through these methods:
|
||||
- Streak counters with celebratory milestones
|
||||
- Progress bars that "celebrate" at 100%
|
||||
- Badge unlocks with animation
|
||||
- Playful stats ("You're on fire! 🔥 5 days in a row")
|
||||
- Playful stats ("You're on fire! 5 days in a row")
|
||||
|
||||
**Form interactions**:
|
||||
- Input fields that animate on focus
|
||||
@@ -196,7 +215,7 @@ Add personality and joy through these methods:
|
||||
- Typing sounds for chat/messaging
|
||||
- Ambient background audio (very subtle)
|
||||
|
||||
**IMPORTANT**:
|
||||
**IMPORTANT**:
|
||||
- Respect system sound settings
|
||||
- Provide mute option
|
||||
- Keep volumes quiet (subtle cues, not alarms)
|
||||
@@ -295,4 +314,3 @@ Test that delight actually delights:
|
||||
- **Accessible**: Works with reduced motion, screen readers
|
||||
|
||||
Remember: Delight is the difference between a tool and an experience. Add personality, surprise users positively, and create moments worth sharing. But always respect usability - delight should enhance, never obstruct.
|
||||
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), brand personality/tone, and everything else that a great human designer would need as well.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Guessing leads to generic design.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel too intense:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel too intense:
|
||||
- What's working? (Don't throw away good ideas)
|
||||
- What's the core message? (Preserve what matters)
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
|
||||
|
||||
## Plan Refinement
|
||||
@@ -96,4 +115,3 @@ Ensure refinement maintains quality:
|
||||
- **Sophistication**: Does it feel more refined and premium?
|
||||
|
||||
Remember: Quiet design is confident design. It doesn't need to shout. Less is more, but less is also harder. Refine with precision and maintain intentionality.
|
||||
|
||||
|
||||
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
@@ -115,4 +134,3 @@ If you removed features or options:
|
||||
- Note any user feedback to monitor
|
||||
|
||||
Remember: You have great taste and judgment. Simplification is an act of confidence - knowing what to keep and courage to remove the rest. As Antoine de Saint-Exupéry said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."
|
||||
|
||||
|
||||
Reference in New Issue
Block a user