Component Architecture

Turn a tangle of one-off components into a composable system: audit what exists, classify it into atomic levels, then refactor the worst offenders into small, typed, documented pieces. The prime directive: a component earns its existence by having one responsibility and a prop interface that makes invalid states unrepresentable. Deliver working refactored code plus an audit the user can act on — never just advice.

When to use / when not to

Use for: component decomposition, prop interface design, variant systems, extracting a shared library, deciding controlled vs uncontrolled, component documentation.

Hand off instead when the real need is:

• Visual tokens (spacing, color, type scales) → skills/frontend-design/design-foundation
• Animation/feedback inside components → skills/frontend-design/interaction-physics
• Keyboard/ARIA behavior of components → skills/frontend-design/accessibility-excellence
• Render performance (memoization, re-renders) → skills/frontend-design/performance-optimization
• Unsure where to start across the whole frontend → skills/frontend-design/frontend-orchestrator

Step 0 — Inspect the codebase, then ask only what's left

Before proposing anything, build a component inventory from the actual code: