diff --git a/dist/claude-code/commands/normalize.md b/dist/claude-code/commands/normalize.md index 5bae0edbc..d67b634af 100644 --- a/dist/claude-code/commands/normalize.md +++ b/dist/claude-code/commands/normalize.md @@ -7,20 +7,62 @@ args: required: false --- -The page, route or feature (we'll call it feature from here on out) provided below or via automatic context looks and feels differently than others. Please do the following: +This command ensures features match your design system's standards and feel cohesive with the rest of your application. Use it when a page, route, or component feels visually or functionally inconsistent with the established patterns. -# Plan +The user provides a feature to normalize (explicitly or via context). This could be a page, route, component, or any interface element that needs design system alignment. - 1. Familiarize yourself with our design system (grep ui guide or design system etc to locate). Don't stop until you deeply understand our UI/UX requirements, our target audience (personas) and type of app. When something isn't immediately clear, ask me. - 2. Analyze the status quo of our feature. What works today, and what doesn't? Why? Assess the situation to see where the gaps are. - 3. Make a plan that, when executed, ensures our feature fits perfectly into the rest of our app, matching our aestethics, taste, design system and goals. Great design is effective design. Think through the best possible UX for our use-case and personas first, then about the visual polish. - -# Execute - Get to work and redesign the feature, in all areas that are still lacking. That could be typography, use of negative space and overall layout, progressive disclosure of sophistication, responsiveness, colors and gradients, motion design, reusing the right design tokens, class names and components, and thoughtful composition and use of established patterns. This is not an exhaustive list. +## Plan -# Clean up - - Ensure DRYness: If your choices led to new components that should be re-usable, find out if we have a shared UI component import path, and consolidate the new components there. - - Delete any now unused or orphaned code or files when you're done. - - This is probably a great time to lint and type-check and ensure we didn't break stuff. Follow the repo's overall guidelines on testing. +Before making changes, deeply understand the context: -Remember: You are a brilliant frontend designer with impeccable taste, you're equally strong in UX and UI, and you are thorough and precise. Your attention of detail and eye for the end-to-end user experience is world class. \ No newline at end of file +1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand: + - Core design principles and aesthetic direction + - Target audience and personas + - Component patterns and conventions + - Design tokens (colors, typography, spacing) + + **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles. + +2. **Analyze the current feature**: Assess what works and what doesn't: + - Where does it deviate from design system patterns? + - Which inconsistencies are cosmetic vs. functional? + - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment? + +3. **Create a normalization plan**: Define specific changes that will align the feature with the design system: + - Which components can be replaced with design system equivalents? + - Which styles need to use design tokens instead of hard-coded values? + - How can UX patterns match established user flows? + + **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first. + +## Execute + +Systematically address all inconsistencies across these dimensions: + +- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes. +- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette. +- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere. +- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns. +- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features. +- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards. +- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements. +- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns. + +**NEVER**: +- Create new one-off components when design system equivalents exist +- Hard-code values that should use design tokens +- Introduce new patterns that diverge from the design system +- Compromise accessibility for visual consistency + +This is not an exhaustive list—apply judgment to identify all areas needing normalization. + +## Clean Up + +After normalization, ensure code quality: + +- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path. +- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization. +- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions. +- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate. + +Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness. \ No newline at end of file diff --git a/dist/codex/prompts/normalize.md b/dist/codex/prompts/normalize.md index ee83e65ed..590c8b786 100644 --- a/dist/codex/prompts/normalize.md +++ b/dist/codex/prompts/normalize.md @@ -3,20 +3,62 @@ description: Normalize design to match your design system and ensure consistency argument-hint: [FEATURE=] --- -The page, route or feature (we'll call it feature from here on out) provided below or via automatic context looks and feels differently than others. Please do the following: +This command ensures features match your design system's standards and feel cohesive with the rest of your application. Use it when a page, route, or component feels visually or functionally inconsistent with the established patterns. -# Plan +The user provides a feature to normalize (explicitly or via context). This could be a page, route, component, or any interface element that needs design system alignment. - 1. Familiarize yourself with our design system (grep ui guide or design system etc to locate). Don't stop until you deeply understand our UI/UX requirements, our target audience (personas) and type of app. When something isn't immediately clear, ask me. - 2. Analyze the status quo of our feature. What works today, and what doesn't? Why? Assess the situation to see where the gaps are. - 3. Make a plan that, when executed, ensures our feature fits perfectly into the rest of our app, matching our aestethics, taste, design system and goals. Great design is effective design. Think through the best possible UX for our use-case and personas first, then about the visual polish. - -# Execute - Get to work and redesign the feature, in all areas that are still lacking. That could be typography, use of negative space and overall layout, progressive disclosure of sophistication, responsiveness, colors and gradients, motion design, reusing the right design tokens, class names and components, and thoughtful composition and use of established patterns. This is not an exhaustive list. +## Plan -# Clean up - - Ensure DRYness: If your choices led to new components that should be re-usable, find out if we have a shared UI component import path, and consolidate the new components there. - - Delete any now unused or orphaned code or files when you're done. - - This is probably a great time to lint and type-check and ensure we didn't break stuff. Follow the repo's overall guidelines on testing. +Before making changes, deeply understand the context: -Remember: You are a brilliant frontend designer with impeccable taste, you're equally strong in UX and UI, and you are thorough and precise. Your attention of detail and eye for the end-to-end user experience is world class. \ No newline at end of file +1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand: + - Core design principles and aesthetic direction + - Target audience and personas + - Component patterns and conventions + - Design tokens (colors, typography, spacing) + + **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles. + +2. **Analyze the current feature**: Assess what works and what doesn't: + - Where does it deviate from design system patterns? + - Which inconsistencies are cosmetic vs. functional? + - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment? + +3. **Create a normalization plan**: Define specific changes that will align the feature with the design system: + - Which components can be replaced with design system equivalents? + - Which styles need to use design tokens instead of hard-coded values? + - How can UX patterns match established user flows? + + **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first. + +## Execute + +Systematically address all inconsistencies across these dimensions: + +- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes. +- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette. +- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere. +- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns. +- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features. +- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards. +- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements. +- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns. + +**NEVER**: +- Create new one-off components when design system equivalents exist +- Hard-code values that should use design tokens +- Introduce new patterns that diverge from the design system +- Compromise accessibility for visual consistency + +This is not an exhaustive list—apply judgment to identify all areas needing normalization. + +## Clean Up + +After normalization, ensure code quality: + +- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path. +- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization. +- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions. +- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate. + +Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness. \ No newline at end of file diff --git a/dist/cursor/commands/normalize.md b/dist/cursor/commands/normalize.md index d01c30d9d..c256a0a2a 100644 --- a/dist/cursor/commands/normalize.md +++ b/dist/cursor/commands/normalize.md @@ -1,17 +1,59 @@ -The page, route or feature (we'll call it feature from here on out) provided below or via automatic context looks and feels differently than others. Please do the following: +This command ensures features match your design system's standards and feel cohesive with the rest of your application. Use it when a page, route, or component feels visually or functionally inconsistent with the established patterns. -# Plan +The user provides a feature to normalize (explicitly or via context). This could be a page, route, component, or any interface element that needs design system alignment. - 1. Familiarize yourself with our design system (grep ui guide or design system etc to locate). Don't stop until you deeply understand our UI/UX requirements, our target audience (personas) and type of app. When something isn't immediately clear, ask me. - 2. Analyze the status quo of our feature. What works today, and what doesn't? Why? Assess the situation to see where the gaps are. - 3. Make a plan that, when executed, ensures our feature fits perfectly into the rest of our app, matching our aestethics, taste, design system and goals. Great design is effective design. Think through the best possible UX for our use-case and personas first, then about the visual polish. - -# Execute - Get to work and redesign the feature, in all areas that are still lacking. That could be typography, use of negative space and overall layout, progressive disclosure of sophistication, responsiveness, colors and gradients, motion design, reusing the right design tokens, class names and components, and thoughtful composition and use of established patterns. This is not an exhaustive list. +## Plan -# Clean up - - Ensure DRYness: If your choices led to new components that should be re-usable, find out if we have a shared UI component import path, and consolidate the new components there. - - Delete any now unused or orphaned code or files when you're done. - - This is probably a great time to lint and type-check and ensure we didn't break stuff. Follow the repo's overall guidelines on testing. +Before making changes, deeply understand the context: -Remember: You are a brilliant frontend designer with impeccable taste, you're equally strong in UX and UI, and you are thorough and precise. Your attention of detail and eye for the end-to-end user experience is world class. \ No newline at end of file +1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand: + - Core design principles and aesthetic direction + - Target audience and personas + - Component patterns and conventions + - Design tokens (colors, typography, spacing) + + **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles. + +2. **Analyze the current feature**: Assess what works and what doesn't: + - Where does it deviate from design system patterns? + - Which inconsistencies are cosmetic vs. functional? + - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment? + +3. **Create a normalization plan**: Define specific changes that will align the feature with the design system: + - Which components can be replaced with design system equivalents? + - Which styles need to use design tokens instead of hard-coded values? + - How can UX patterns match established user flows? + + **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first. + +## Execute + +Systematically address all inconsistencies across these dimensions: + +- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes. +- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette. +- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere. +- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns. +- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features. +- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards. +- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements. +- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns. + +**NEVER**: +- Create new one-off components when design system equivalents exist +- Hard-code values that should use design tokens +- Introduce new patterns that diverge from the design system +- Compromise accessibility for visual consistency + +This is not an exhaustive list—apply judgment to identify all areas needing normalization. + +## Clean Up + +After normalization, ensure code quality: + +- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path. +- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization. +- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions. +- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate. + +Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness. \ No newline at end of file diff --git a/dist/gemini/commands/normalize.toml b/dist/gemini/commands/normalize.toml index 75d24213e..5be812a81 100644 --- a/dist/gemini/commands/normalize.toml +++ b/dist/gemini/commands/normalize.toml @@ -1,20 +1,62 @@ description = "Normalize design to match your design system and ensure consistency" prompt = """ -The page, route or feature (we'll call it feature from here on out) provided below or via automatic context looks and feels differently than others. Please do the following: +This command ensures features match your design system's standards and feel cohesive with the rest of your application. Use it when a page, route, or component feels visually or functionally inconsistent with the established patterns. -# Plan +The user provides a feature to normalize (explicitly or via context). This could be a page, route, component, or any interface element that needs design system alignment. - 1. Familiarize yourself with our design system (grep ui guide or design system etc to locate). Don't stop until you deeply understand our UI/UX requirements, our target audience (personas) and type of app. When something isn't immediately clear, ask me. - 2. Analyze the status quo of our feature. What works today, and what doesn't? Why? Assess the situation to see where the gaps are. - 3. Make a plan that, when executed, ensures our feature fits perfectly into the rest of our app, matching our aestethics, taste, design system and goals. Great design is effective design. Think through the best possible UX for our use-case and personas first, then about the visual polish. - -# Execute - Get to work and redesign the feature, in all areas that are still lacking. That could be typography, use of negative space and overall layout, progressive disclosure of sophistication, responsiveness, colors and gradients, motion design, reusing the right design tokens, class names and components, and thoughtful composition and use of established patterns. This is not an exhaustive list. +## Plan -# Clean up - - Ensure DRYness: If your choices led to new components that should be re-usable, find out if we have a shared UI component import path, and consolidate the new components there. - - Delete any now unused or orphaned code or files when you're done. - - This is probably a great time to lint and type-check and ensure we didn't break stuff. Follow the repo's overall guidelines on testing. +Before making changes, deeply understand the context: -Remember: You are a brilliant frontend designer with impeccable taste, you're equally strong in UX and UI, and you are thorough and precise. Your attention of detail and eye for the end-to-end user experience is world class. +1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand: + - Core design principles and aesthetic direction + - Target audience and personas + - Component patterns and conventions + - Design tokens (colors, typography, spacing) + + **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles. + +2. **Analyze the current feature**: Assess what works and what doesn't: + - Where does it deviate from design system patterns? + - Which inconsistencies are cosmetic vs. functional? + - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment? + +3. **Create a normalization plan**: Define specific changes that will align the feature with the design system: + - Which components can be replaced with design system equivalents? + - Which styles need to use design tokens instead of hard-coded values? + - How can UX patterns match established user flows? + + **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first. + +## Execute + +Systematically address all inconsistencies across these dimensions: + +- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes. +- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette. +- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere. +- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns. +- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features. +- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards. +- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements. +- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns. + +**NEVER**: +- Create new one-off components when design system equivalents exist +- Hard-code values that should use design tokens +- Introduce new patterns that diverge from the design system +- Compromise accessibility for visual consistency + +This is not an exhaustive list—apply judgment to identify all areas needing normalization. + +## Clean Up + +After normalization, ensure code quality: + +- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path. +- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization. +- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions. +- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate. + +Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness. """ \ No newline at end of file diff --git a/source/commands/normalize.md b/source/commands/normalize.md index abf5c144d..d203cdede 100644 --- a/source/commands/normalize.md +++ b/source/commands/normalize.md @@ -7,20 +7,62 @@ args: required: false --- -The page, route or feature (we'll call it feature from here on out) provided below or via automatic context looks and feels differently than others. Please do the following: +This command ensures features match your design system's standards and feel cohesive with the rest of your application. Use it when a page, route, or component feels visually or functionally inconsistent with the established patterns. -# Plan +The user provides a feature to normalize (explicitly or via context). This could be a page, route, component, or any interface element that needs design system alignment. - 1. Familiarize yourself with our design system (grep ui guide or design system etc to locate). Don't stop until you deeply understand our UI/UX requirements, our target audience (personas) and type of app. When something isn't immediately clear, ask me. - 2. Analyze the status quo of our feature. What works today, and what doesn't? Why? Assess the situation to see where the gaps are. - 3. Make a plan that, when executed, ensures our feature fits perfectly into the rest of our app, matching our aestethics, taste, design system and goals. Great design is effective design. Think through the best possible UX for our use-case and personas first, then about the visual polish. - -# Execute - Get to work and redesign the feature, in all areas that are still lacking. That could be typography, use of negative space and overall layout, progressive disclosure of sophistication, responsiveness, colors and gradients, motion design, reusing the right design tokens, class names and components, and thoughtful composition and use of established patterns. This is not an exhaustive list. +## Plan -# Clean up - - Ensure DRYness: If your choices led to new components that should be re-usable, find out if we have a shared UI component import path, and consolidate the new components there. - - Delete any now unused or orphaned code or files when you're done. - - This is probably a great time to lint and type-check and ensure we didn't break stuff. Follow the repo's overall guidelines on testing. +Before making changes, deeply understand the context: -Remember: You are a brilliant frontend designer with impeccable taste, you're equally strong in UX and UI, and you are thorough and precise. Your attention of detail and eye for the end-to-end user experience is world class. +1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand: + - Core design principles and aesthetic direction + - Target audience and personas + - Component patterns and conventions + - Design tokens (colors, typography, spacing) + + **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles. + +2. **Analyze the current feature**: Assess what works and what doesn't: + - Where does it deviate from design system patterns? + - Which inconsistencies are cosmetic vs. functional? + - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment? + +3. **Create a normalization plan**: Define specific changes that will align the feature with the design system: + - Which components can be replaced with design system equivalents? + - Which styles need to use design tokens instead of hard-coded values? + - How can UX patterns match established user flows? + + **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first. + +## Execute + +Systematically address all inconsistencies across these dimensions: + +- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes. +- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette. +- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere. +- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns. +- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features. +- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards. +- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements. +- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns. + +**NEVER**: +- Create new one-off components when design system equivalents exist +- Hard-code values that should use design tokens +- Introduce new patterns that diverge from the design system +- Compromise accessibility for visual consistency + +This is not an exhaustive list—apply judgment to identify all areas needing normalization. + +## Clean Up + +After normalization, ensure code quality: + +- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path. +- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization. +- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions. +- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate. + +Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness.