I Distill

Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.

MANDATORY PREPARATION

Read ${CLAUDE_CONFIG_DIR:-~/.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.

Assess Current State

Analyze what makes the design feel complex or cluttered:

1. Identify complexity sources:

   • Too many elements: Competing buttons, redundant information, visual clutter
   • Excessive variation: Too many colors, fonts, sizes, styles without purpose
   • Information overload: Everything visible at once, no progressive disclosure
   • Visual noise: Unnecessary borders, shadows, backgrounds, decorations
   • Confusing hierarchy: Unclear what matters most
   • Feature creep: Too many options, actions, or paths forward

2. Find the essence:

   • What's the primary user goal? (There should be ONE)
   • What's actually necessary vs nice-to-have?
   • What can be removed, hidden, or combined?
   • What's the 20% that delivers 80% of value?

If any of these are not answered by design context (design/context.md, .impeccable.md, or design/direction.md), STOP and call the AskUserQuestion tool to clarify. Use the answer to inform your simplification strategy. If the answer is unclear or deferred, proceed by removing redundancy while preserving all functionality.

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

Create a ruthless editing strategy:

• Core purpose: What's the ONE thing this should accomplish?
• Essential elements: What's truly necessary to achieve that purpose?
• Progressive disclosure: What can be hidden until needed?
• Consolidation opportunities: What can be combined or integrated?

IMPORTANT: Simplification is hard. It requires saying no to good ideas to make room for great execution. Be ruthless.

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.

Simplify the Design

Remove complexity across these dimensions:

• Information architecture: ONE primary action, few secondary, everything else tertiary or hidden behind progressive disclosure. Merge similar actions; cut anything said elsewhere.
• Visual: cap the palette at 1-2 colors plus neutrals; one font family, 3-4 sizes, 2-3 weights. Strip decorations that don't serve hierarchy. Never nest cards inside cards — cards aren't needed for basic layout; use spacing and alignment instead.
• Layout: prefer linear vertical flow over complex grids; consistent alignment and one spacing scale. (See /i-layout for spacing and rhythm.)
• Interaction: fewer choices, smart defaults, inline over modal, ONE obvious next step.
• Content: cut copy hard, say it once. (See /i-clarify for voice and labeling.)
• Code: remove dead CSS and orphaned files, flatten component trees, reduce variants (does it need 12, or do 3 cover 90%?).

NEVER:

• Remove necessary functionality (simplicity ≠ feature-less)
• Sacrifice accessibility for simplicity (clear labels and ARIA still required)
• Make things so simple they're unclear (mystery ≠ minimalism)
• Remove information users need to make decisions
• Eliminate hierarchy completely (some things should stand out)
• Oversimplify complex domains (match complexity to actual task complexity)

Verify Simplification

Ensure simplification improves usability:

• Faster task completion: Can users accomplish goals more quickly?
• Reduced cognitive load: Is it easier to understand what to do?
• Still complete: Are all necessary features still accessible?
• Clearer hierarchy: Is it obvious what matters most?
• Better performance: Does simpler design load faster?

Document Removed Complexity

If you removed features or options:

• Document why they were removed
• Consider if they need alternative access points
• Note any user feedback to monitor

Remember: simplification is an act of confidence — knowing what to keep and having the courage to remove the rest.

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)