i-normalize

name	i-normalize
description	Use when the user says: "normalize the design", "make it consistent", "align with design system". Normalize design consistency across the interface.
user-invocable	true

Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.

MANDATORY PREPARATION

Read ~/.claude/skills/i-frontend-design/SKILL.md for design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run /i-teach-impeccable first.

---

Plan

Before making changes, deeply understand the context:

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.

   If no design system is found after searching, STOP and ask:

   AskUserQuestion:
     question: "No design system found. How should we establish consistency?"
     header: "No system"
     options:
       - label: "Extract from codebase"
         description: "Use /i-extract to identify and systematize the patterns already in the code"
       - label: "Normalize to existing patterns"
         description: "Use the most common patterns already in the codebase as the standard"
       - label: "Define principles now"
         description: "I'll describe what I want and we'll build from there"
   

   If "Extract from codebase" → tell the user to run /i-extract first, then return to /i-normalize afterward to apply the extracted system.

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.

---

Propose Changes

After analyzing the current state, present your proposed changes to the user:

1. Assessment: What's wrong and why (your domain analysis above)
2. Proposed changes: Specific changes ranked by impact, with rationale
3. Verification plan: What to check after implementation (LLM self-check items + Playwright verification if available)

Then STOP and confirm before implementing:

AskUserQuestion:
  question: "Here's what I propose. How would you like to proceed?"
  header: "Confirm"
  options:
    - label: "Implement"
      description: "Looks good — go ahead and make these changes."
    - label: "Refine scope"
      description: "I want to adjust what's included before you start."
    - label: "Challenge this first"
      description: "I'll run /mine.challenge against your proposal before we proceed."
    - label: "Stop here"
      description: "Don't implement anything. The proposal is in this conversation only."

If "Implement" → proceed to implementation below. If "Refine scope" → ask what to change, update proposal, re-confirm.

If "Challenge this first" → invoke /mine.challenge inline against the proposal, read findings, revise proposal, re-present this gate. If "Stop here" → end the skill.

---

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.

Completion

After implementation, summarize in conversation:

1. Changes made: List each file changed and what was done
2. Verification: LLM self-check results (anti-pattern scan, consistency check). Note if Playwright was available for visual verification.
3. Suggested next step: Any follow-up skills that would complement this work (e.g., after /i-typeset, suggest /i-polish for a final pass)