diff --git a/.claude/commands/animate.md b/.claude/commands/animate.md index 5b1ad36c3..6c2f26a07 100644 --- a/.claude/commands/animate.md +++ b/.claude/commands/animate.md @@ -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 diff --git a/.claude/commands/bolder.md b/.claude/commands/bolder.md index 66adefefe..73d3128ab 100644 --- a/.claude/commands/bolder.md +++ b/.claude/commands/bolder.md @@ -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: diff --git a/.claude/commands/colorize.md b/.claude/commands/colorize.md index 0d8a93933..36c0d0045 100644 --- a/.claude/commands/colorize.md +++ b/.claude/commands/colorize.md @@ -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 diff --git a/.claude/commands/delight.md b/.claude/commands/delight.md index 942cfb991..788904b19 100644 --- a/.claude/commands/delight.md +++ b/.claude/commands/delight.md @@ -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) diff --git a/.claude/commands/quieter.md b/.claude/commands/quieter.md index 781b49f48..889991286 100644 --- a/.claude/commands/quieter.md +++ b/.claude/commands/quieter.md @@ -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 diff --git a/.claude/commands/simplify.md b/.claude/commands/simplify.md index 11767ab95..8f0f1419e 100644 --- a/.claude/commands/simplify.md +++ b/.claude/commands/simplify.md @@ -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 diff --git a/dist/claude-code-prefixed/.claude/commands/i-animate.md b/dist/claude-code-prefixed/.claude/commands/i-animate.md index f795552ff..089da67a1 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-animate.md +++ b/dist/claude-code-prefixed/.claude/commands/i-animate.md @@ -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 diff --git a/dist/claude-code-prefixed/.claude/commands/i-bolder.md b/dist/claude-code-prefixed/.claude/commands/i-bolder.md index 3b53d981f..39c647602 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-bolder.md +++ b/dist/claude-code-prefixed/.claude/commands/i-bolder.md @@ -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: diff --git a/dist/claude-code-prefixed/.claude/commands/i-colorize.md b/dist/claude-code-prefixed/.claude/commands/i-colorize.md index 4c473460b..9ce2c677c 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-colorize.md +++ b/dist/claude-code-prefixed/.claude/commands/i-colorize.md @@ -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 diff --git a/dist/claude-code-prefixed/.claude/commands/i-delight.md b/dist/claude-code-prefixed/.claude/commands/i-delight.md index d0f861153..3b408b4d7 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-delight.md +++ b/dist/claude-code-prefixed/.claude/commands/i-delight.md @@ -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) diff --git a/dist/claude-code-prefixed/.claude/commands/i-quieter.md b/dist/claude-code-prefixed/.claude/commands/i-quieter.md index 6c126e868..501d7b480 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-quieter.md +++ b/dist/claude-code-prefixed/.claude/commands/i-quieter.md @@ -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 diff --git a/dist/claude-code-prefixed/.claude/commands/i-simplify.md b/dist/claude-code-prefixed/.claude/commands/i-simplify.md index 623e5b5eb..499c53145 100644 --- a/dist/claude-code-prefixed/.claude/commands/i-simplify.md +++ b/dist/claude-code-prefixed/.claude/commands/i-simplify.md @@ -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 diff --git a/dist/claude-code/.claude/commands/animate.md b/dist/claude-code/.claude/commands/animate.md index 5b1ad36c3..6c2f26a07 100644 --- a/dist/claude-code/.claude/commands/animate.md +++ b/dist/claude-code/.claude/commands/animate.md @@ -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 diff --git a/dist/claude-code/.claude/commands/bolder.md b/dist/claude-code/.claude/commands/bolder.md index 66adefefe..73d3128ab 100644 --- a/dist/claude-code/.claude/commands/bolder.md +++ b/dist/claude-code/.claude/commands/bolder.md @@ -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: diff --git a/dist/claude-code/.claude/commands/colorize.md b/dist/claude-code/.claude/commands/colorize.md index 0d8a93933..36c0d0045 100644 --- a/dist/claude-code/.claude/commands/colorize.md +++ b/dist/claude-code/.claude/commands/colorize.md @@ -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 diff --git a/dist/claude-code/.claude/commands/delight.md b/dist/claude-code/.claude/commands/delight.md index 942cfb991..788904b19 100644 --- a/dist/claude-code/.claude/commands/delight.md +++ b/dist/claude-code/.claude/commands/delight.md @@ -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) diff --git a/dist/claude-code/.claude/commands/quieter.md b/dist/claude-code/.claude/commands/quieter.md index 781b49f48..889991286 100644 --- a/dist/claude-code/.claude/commands/quieter.md +++ b/dist/claude-code/.claude/commands/quieter.md @@ -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 diff --git a/dist/claude-code/.claude/commands/simplify.md b/dist/claude-code/.claude/commands/simplify.md index 11767ab95..8f0f1419e 100644 --- a/dist/claude-code/.claude/commands/simplify.md +++ b/dist/claude-code/.claude/commands/simplify.md @@ -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 diff --git a/dist/codex-prefixed/.codex/prompts/i-animate.md b/dist/codex-prefixed/.codex/prompts/i-animate.md index ed5158930..91a86403f 100644 --- a/dist/codex-prefixed/.codex/prompts/i-animate.md +++ b/dist/codex-prefixed/.codex/prompts/i-animate.md @@ -3,10 +3,27 @@ description: Review a feature and enhance it with purposeful animations, micro-i argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex-prefixed/.codex/prompts/i-bolder.md b/dist/codex-prefixed/.codex/prompts/i-bolder.md index d32e57ac7..93c2780c0 100644 --- a/dist/codex-prefixed/.codex/prompts/i-bolder.md +++ b/dist/codex-prefixed/.codex/prompts/i-bolder.md @@ -3,10 +3,27 @@ description: Amplify safe or boring designs to make them more visually interesti argument-hint: [TARGET=] --- -**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: diff --git a/dist/codex-prefixed/.codex/prompts/i-colorize.md b/dist/codex-prefixed/.codex/prompts/i-colorize.md index e69409d89..0cb492851 100644 --- a/dist/codex-prefixed/.codex/prompts/i-colorize.md +++ b/dist/codex-prefixed/.codex/prompts/i-colorize.md @@ -3,10 +3,27 @@ description: Add strategic color to features that are too monochromatic or lack argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex-prefixed/.codex/prompts/i-delight.md b/dist/codex-prefixed/.codex/prompts/i-delight.md index 74d9f07a2..19db53666 100644 --- a/dist/codex-prefixed/.codex/prompts/i-delight.md +++ b/dist/codex-prefixed/.codex/prompts/i-delight.md @@ -3,10 +3,27 @@ description: Add moments of joy, personality, and unexpected touches that make i argument-hint: [TARGET=] --- -**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) diff --git a/dist/codex-prefixed/.codex/prompts/i-quieter.md b/dist/codex-prefixed/.codex/prompts/i-quieter.md index 7e5560e29..10e4f871c 100644 --- a/dist/codex-prefixed/.codex/prompts/i-quieter.md +++ b/dist/codex-prefixed/.codex/prompts/i-quieter.md @@ -3,10 +3,27 @@ description: Tone down overly bold or visually aggressive designs. Reduces inten argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex-prefixed/.codex/prompts/i-simplify.md b/dist/codex-prefixed/.codex/prompts/i-simplify.md index c9c93babc..191f5d587 100644 --- a/dist/codex-prefixed/.codex/prompts/i-simplify.md +++ b/dist/codex-prefixed/.codex/prompts/i-simplify.md @@ -3,10 +3,27 @@ description: Strip designs to their essence by removing unnecessary complexity. argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex/.codex/prompts/animate.md b/dist/codex/.codex/prompts/animate.md index ed5158930..91a86403f 100644 --- a/dist/codex/.codex/prompts/animate.md +++ b/dist/codex/.codex/prompts/animate.md @@ -3,10 +3,27 @@ description: Review a feature and enhance it with purposeful animations, micro-i argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex/.codex/prompts/bolder.md b/dist/codex/.codex/prompts/bolder.md index d32e57ac7..93c2780c0 100644 --- a/dist/codex/.codex/prompts/bolder.md +++ b/dist/codex/.codex/prompts/bolder.md @@ -3,10 +3,27 @@ description: Amplify safe or boring designs to make them more visually interesti argument-hint: [TARGET=] --- -**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: diff --git a/dist/codex/.codex/prompts/colorize.md b/dist/codex/.codex/prompts/colorize.md index e69409d89..0cb492851 100644 --- a/dist/codex/.codex/prompts/colorize.md +++ b/dist/codex/.codex/prompts/colorize.md @@ -3,10 +3,27 @@ description: Add strategic color to features that are too monochromatic or lack argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex/.codex/prompts/delight.md b/dist/codex/.codex/prompts/delight.md index 74d9f07a2..19db53666 100644 --- a/dist/codex/.codex/prompts/delight.md +++ b/dist/codex/.codex/prompts/delight.md @@ -3,10 +3,27 @@ description: Add moments of joy, personality, and unexpected touches that make i argument-hint: [TARGET=] --- -**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) diff --git a/dist/codex/.codex/prompts/quieter.md b/dist/codex/.codex/prompts/quieter.md index 7e5560e29..10e4f871c 100644 --- a/dist/codex/.codex/prompts/quieter.md +++ b/dist/codex/.codex/prompts/quieter.md @@ -3,10 +3,27 @@ description: Tone down overly bold or visually aggressive designs. Reduces inten argument-hint: [TARGET=] --- -**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 diff --git a/dist/codex/.codex/prompts/simplify.md b/dist/codex/.codex/prompts/simplify.md index c9c93babc..191f5d587 100644 --- a/dist/codex/.codex/prompts/simplify.md +++ b/dist/codex/.codex/prompts/simplify.md @@ -3,10 +3,27 @@ description: Strip designs to their essence by removing unnecessary complexity. argument-hint: [TARGET=] --- -**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 diff --git a/dist/cursor-prefixed/.cursor/commands/i-animate.md b/dist/cursor-prefixed/.cursor/commands/i-animate.md index ea19b6a84..cee6e4352 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-animate.md +++ b/dist/cursor-prefixed/.cursor/commands/i-animate.md @@ -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 diff --git a/dist/cursor-prefixed/.cursor/commands/i-bolder.md b/dist/cursor-prefixed/.cursor/commands/i-bolder.md index 559f5351e..b5db9cd17 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-bolder.md +++ b/dist/cursor-prefixed/.cursor/commands/i-bolder.md @@ -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: diff --git a/dist/cursor-prefixed/.cursor/commands/i-colorize.md b/dist/cursor-prefixed/.cursor/commands/i-colorize.md index d1464377b..fda05e6d8 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-colorize.md +++ b/dist/cursor-prefixed/.cursor/commands/i-colorize.md @@ -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 diff --git a/dist/cursor-prefixed/.cursor/commands/i-delight.md b/dist/cursor-prefixed/.cursor/commands/i-delight.md index e2cd86f48..9cf9fda1d 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-delight.md +++ b/dist/cursor-prefixed/.cursor/commands/i-delight.md @@ -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) diff --git a/dist/cursor-prefixed/.cursor/commands/i-quieter.md b/dist/cursor-prefixed/.cursor/commands/i-quieter.md index 2f2f610b2..9a75d5dd3 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-quieter.md +++ b/dist/cursor-prefixed/.cursor/commands/i-quieter.md @@ -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 diff --git a/dist/cursor-prefixed/.cursor/commands/i-simplify.md b/dist/cursor-prefixed/.cursor/commands/i-simplify.md index 1a0bb0072..de0dc1e4c 100644 --- a/dist/cursor-prefixed/.cursor/commands/i-simplify.md +++ b/dist/cursor-prefixed/.cursor/commands/i-simplify.md @@ -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 diff --git a/dist/cursor/.cursor/commands/animate.md b/dist/cursor/.cursor/commands/animate.md index ea19b6a84..cee6e4352 100644 --- a/dist/cursor/.cursor/commands/animate.md +++ b/dist/cursor/.cursor/commands/animate.md @@ -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 diff --git a/dist/cursor/.cursor/commands/bolder.md b/dist/cursor/.cursor/commands/bolder.md index 559f5351e..b5db9cd17 100644 --- a/dist/cursor/.cursor/commands/bolder.md +++ b/dist/cursor/.cursor/commands/bolder.md @@ -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: diff --git a/dist/cursor/.cursor/commands/colorize.md b/dist/cursor/.cursor/commands/colorize.md index d1464377b..fda05e6d8 100644 --- a/dist/cursor/.cursor/commands/colorize.md +++ b/dist/cursor/.cursor/commands/colorize.md @@ -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 diff --git a/dist/cursor/.cursor/commands/delight.md b/dist/cursor/.cursor/commands/delight.md index e2cd86f48..9cf9fda1d 100644 --- a/dist/cursor/.cursor/commands/delight.md +++ b/dist/cursor/.cursor/commands/delight.md @@ -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) diff --git a/dist/cursor/.cursor/commands/quieter.md b/dist/cursor/.cursor/commands/quieter.md index 2f2f610b2..9a75d5dd3 100644 --- a/dist/cursor/.cursor/commands/quieter.md +++ b/dist/cursor/.cursor/commands/quieter.md @@ -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 diff --git a/dist/cursor/.cursor/commands/simplify.md b/dist/cursor/.cursor/commands/simplify.md index 1a0bb0072..de0dc1e4c 100644 --- a/dist/cursor/.cursor/commands/simplify.md +++ b/dist/cursor/.cursor/commands/simplify.md @@ -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 diff --git a/dist/gemini-prefixed/.gemini/commands/i-animate.toml b/dist/gemini-prefixed/.gemini/commands/i-animate.toml index b9f62dcf2..6f59c9003 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-animate.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-animate.toml @@ -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 diff --git a/dist/gemini-prefixed/.gemini/commands/i-bolder.toml b/dist/gemini-prefixed/.gemini/commands/i-bolder.toml index a893dcfdf..bd4712456 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-bolder.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-bolder.toml @@ -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: diff --git a/dist/gemini-prefixed/.gemini/commands/i-colorize.toml b/dist/gemini-prefixed/.gemini/commands/i-colorize.toml index da311481e..90c3e511e 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-colorize.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-colorize.toml @@ -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 diff --git a/dist/gemini-prefixed/.gemini/commands/i-delight.toml b/dist/gemini-prefixed/.gemini/commands/i-delight.toml index 54944dfdc..5de760d8e 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-delight.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-delight.toml @@ -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) diff --git a/dist/gemini-prefixed/.gemini/commands/i-quieter.toml b/dist/gemini-prefixed/.gemini/commands/i-quieter.toml index 1f21941c7..10f017687 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-quieter.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-quieter.toml @@ -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 diff --git a/dist/gemini-prefixed/.gemini/commands/i-simplify.toml b/dist/gemini-prefixed/.gemini/commands/i-simplify.toml index 8bcd9e074..a8f6f8ff5 100644 --- a/dist/gemini-prefixed/.gemini/commands/i-simplify.toml +++ b/dist/gemini-prefixed/.gemini/commands/i-simplify.toml @@ -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 diff --git a/dist/gemini/.gemini/commands/animate.toml b/dist/gemini/.gemini/commands/animate.toml index b9f62dcf2..6f59c9003 100644 --- a/dist/gemini/.gemini/commands/animate.toml +++ b/dist/gemini/.gemini/commands/animate.toml @@ -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 diff --git a/dist/gemini/.gemini/commands/bolder.toml b/dist/gemini/.gemini/commands/bolder.toml index a893dcfdf..bd4712456 100644 --- a/dist/gemini/.gemini/commands/bolder.toml +++ b/dist/gemini/.gemini/commands/bolder.toml @@ -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: diff --git a/dist/gemini/.gemini/commands/colorize.toml b/dist/gemini/.gemini/commands/colorize.toml index da311481e..90c3e511e 100644 --- a/dist/gemini/.gemini/commands/colorize.toml +++ b/dist/gemini/.gemini/commands/colorize.toml @@ -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 diff --git a/dist/gemini/.gemini/commands/delight.toml b/dist/gemini/.gemini/commands/delight.toml index 54944dfdc..5de760d8e 100644 --- a/dist/gemini/.gemini/commands/delight.toml +++ b/dist/gemini/.gemini/commands/delight.toml @@ -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) diff --git a/dist/gemini/.gemini/commands/quieter.toml b/dist/gemini/.gemini/commands/quieter.toml index 1f21941c7..10f017687 100644 --- a/dist/gemini/.gemini/commands/quieter.toml +++ b/dist/gemini/.gemini/commands/quieter.toml @@ -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 diff --git a/dist/gemini/.gemini/commands/simplify.toml b/dist/gemini/.gemini/commands/simplify.toml index 8bcd9e074..a8f6f8ff5 100644 --- a/dist/gemini/.gemini/commands/simplify.toml +++ b/dist/gemini/.gemini/commands/simplify.toml @@ -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 diff --git a/source/commands/animate.md b/source/commands/animate.md index 1d8429b61..b19c60fdd 100644 --- a/source/commands/animate.md +++ b/source/commands/animate.md @@ -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. - diff --git a/source/commands/bolder.md b/source/commands/bolder.md index c89996723..234f55d25 100644 --- a/source/commands/bolder.md +++ b/source/commands/bolder.md @@ -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. - diff --git a/source/commands/colorize.md b/source/commands/colorize.md index 7e3bb2af1..3a1c883f3 100644 --- a/source/commands/colorize.md +++ b/source/commands/colorize.md @@ -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. - diff --git a/source/commands/delight.md b/source/commands/delight.md index 1619303b3..00166363e 100644 --- a/source/commands/delight.md +++ b/source/commands/delight.md @@ -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. - diff --git a/source/commands/quieter.md b/source/commands/quieter.md index e84dcc4fd..70b01e4ed 100644 --- a/source/commands/quieter.md +++ b/source/commands/quieter.md @@ -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. - diff --git a/source/commands/simplify.md b/source/commands/simplify.md index b7ca23db4..14e224dae 100644 --- a/source/commands/simplify.md +++ b/source/commands/simplify.md @@ -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." -