i-arrange

name	i-arrange
description	Use when the user says: "fix the layout", "arrange this", "visual hierarchy". Improve layout, spatial design, structure, and alignment.
user-invocable	true

Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.

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.

---

Assess Current Layout

Analyze what's weak about the current spatial design:

1. Spacing:

   • Is spacing consistent or arbitrary? (Random padding/margin values)
   • Is all spacing the same? (Equal padding everywhere = no rhythm)
   • Are related elements grouped tightly, with generous space between groups?

2. Visual hierarchy:

   • Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
   • Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
   • Does whitespace guide the eye to what matters?

3. Grid & structure:

   • Is there a clear underlying structure, or does the layout feel random?
   • Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
   • Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)

4. Rhythm & variety:

   • Does the layout have visual rhythm? (Alternating tight/generous spacing)
   • Is every section structured the same way? (Monotonous repetition)
   • Are there intentional moments of surprise or emphasis?

5. Density:

   • Is the layout too cramped? (Not enough breathing room)
   • Is the layout too sparse? (Excessive whitespace without purpose)
   • Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)

CRITICAL: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.

Plan Layout Improvements

Consult the spatial design reference for detailed guidance on grids, rhythm, and container queries.

Create a systematic plan:

• Spacing system: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
• Hierarchy strategy: How will space communicate importance?
• Layout approach: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
• Rhythm: Where should spacing be tight vs generous?

---

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.

---

Improve Layout Systematically

Establish a Spacing System

• Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
• Name tokens semantically if using custom properties: --space-xs through --space-xl, not --spacing-8
• Use gap for sibling spacing instead of margins — eliminates margin collapse hacks
• Apply clamp() for fluid spacing that breathes on larger screens

Create Visual Rhythm

• Tight grouping for related elements (8-12px between siblings)
• Generous separation between distinct sections (48-96px)
• Varied spacing within sections — not every row needs the same gap
• Asymmetric compositions — break the predictable centered-content pattern when it makes sense

Choose the Right Layout Tool

• Use Flexbox for 1D layouts: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
• Use Grid for 2D layouts: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
• Don't default to Grid when Flexbox with flex-wrap would be simpler and more flexible.
• Use repeat(auto-fit, minmax(280px, 1fr)) for responsive grids without breakpoints.
• Use named grid areas (grid-template-areas) for complex page layouts — redefine at breakpoints.

Break Card Grid Monotony

• Don't default to card grids for everything — spacing and alignment create visual grouping naturally
• Use cards only when content is truly distinct and actionable — never nest cards inside cards
• Vary card sizes, span columns, or mix cards with non-card content to break repetition

Strengthen Visual Hierarchy

• Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
• Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
• Create clear content groupings through proximity and separation.

Manage Depth & Elevation

• Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
• Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
• Use elevation to reinforce hierarchy, not as decoration

Optical Adjustments

• If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.

NEVER:

• Use arbitrary spacing values outside your scale
• Make all spacing equal — variety creates hierarchy
• Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
• Use arbitrary z-index values (999, 9999) — build a semantic scale

Also avoid all layout anti-patterns in the anti-patterns reference (card wrapping, nested cards, identical card grids, centering everything, hero metric template).

Verify Layout Improvements

• Squint test: Can you identify primary, secondary, and groupings with blurred vision?
• Rhythm: Does the page have a satisfying beat of tight and generous spacing?
• Hierarchy: Is the most important content obvious within 2 seconds?
• Breathing room: Does the layout feel comfortable, not cramped or wasteful?
• Consistency: Is the spacing system applied uniformly?
• Responsiveness: Does the layout adapt gracefully across screen sizes?

Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.

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)