home / skills / steveclarke / dotfiles / i-extract

i-extract skill

/ai/skills/i-extract

This skill identifies reusable patterns and design tokens and consolidates them into a design system for systematic reuse.

npx playbooks add skill steveclarke/dotfiles --skill i-extract

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.8 KB
---
name: i-extract
description: Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library.
user-invokable: true
args:
  - name: target
    description: The feature, component, or area to extract from (optional)
    required: false
---

Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.

## Discover

Analyze the target area to identify extraction opportunities:

1. **Find the design system**: Locate your design system, component library, or shared UI directory (grep for "design system", "ui", "components", etc.). Understand its structure:
   - Component organization and naming conventions
   - Design token structure (if any)
   - Documentation patterns
   - Import/export conventions
   
   **CRITICAL**: If no design system exists, ask before creating one. Understand the preferred location and structure first.

2. **Identify patterns**: Look for:
   - **Repeated components**: Similar UI patterns used multiple times (buttons, cards, inputs, etc.)
   - **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
   - **Inconsistent variations**: Multiple implementations of the same concept (3 different button styles)
   - **Reusable patterns**: Layout patterns, composition patterns, interaction patterns worth systematizing

3. **Assess value**: Not everything should be extracted. Consider:
   - Is this used 3+ times, or likely to be reused?
   - Would systematizing this improve consistency?
   - Is this a general pattern or context-specific?
   - What's the maintenance cost vs benefit?

## Plan Extraction

Create a systematic extraction plan:

- **Components to extract**: Which UI elements become reusable components?
- **Tokens to create**: Which hard-coded values become design tokens?
- **Variants to support**: What variations does each component need?
- **Naming conventions**: Component names, token names, prop names that match existing patterns
- **Migration path**: How to refactor existing uses to consume the new shared versions

**IMPORTANT**: Design systems grow incrementally. Extract what's clearly reusable now, not everything that might someday be reusable.

## Extract & Enrich

Build improved, reusable versions:

- **Components**: Create well-designed components with:
  - Clear props API with sensible defaults
  - Proper variants for different use cases
  - Accessibility built in (ARIA, keyboard navigation, focus management)
  - Documentation and usage examples
  
- **Design tokens**: Create tokens with:
  - Clear naming (primitive vs semantic)
  - Proper hierarchy and organization
  - Documentation of when to use each token
  
- **Patterns**: Document patterns with:
  - When to use this pattern
  - Code examples
  - Variations and combinations

**NEVER**:
- Extract one-off, context-specific implementations without generalization
- Create components so generic they're useless
- Extract without considering existing design system conventions
- Skip proper TypeScript types or prop documentation
- Create tokens for every single value (tokens should have semantic meaning)

## Migrate

Replace existing uses with the new shared versions:

- **Find all instances**: Search for the patterns you've extracted
- **Replace systematically**: Update each use to consume the shared version
- **Test thoroughly**: Ensure visual and functional parity
- **Delete dead code**: Remove the old implementations

## Document

Update design system documentation:

- Add new components to the component library
- Document token usage and values
- Add examples and guidelines
- Update any Storybook or component catalog

Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.

Overview

This skill extracts and consolidates reusable UI components, design tokens, and interaction patterns into a maintainable design system. It identifies repetition and inconsistency, plans pragmatic extractions, builds accessible reusable artifacts, and guides safe migration and documentation. The goal is systematic reuse, visual consistency, and lower maintenance cost across projects.

How this skill works

The skill scans a target codebase or UI directory to locate existing design system artifacts and repeated patterns. It assesses reuse value, produces a prioritized extraction plan (components, tokens, variants, names, migration path), then implements improved components and tokens with accessibility, docs, and examples. Finally it replaces occurrences, tests parity, removes dead code, and updates the design system catalog.

When to use it

  • When multiple projects or pages have similar UI pieces implemented differently
  • When hard-coded colors, spacing, or typography appear across files
  • When you need to centralize styling and behavior for consistency
  • When onboarding contributors who must follow shared UI conventions
  • When preparing a component library, design system, or Storybook catalog

Best practices

  • Confirm an existing design system location and conventions before creating new structure
  • Extract only patterns that are clearly reusable now; prioritize high-value items
  • Choose semantic tokens (purpose-first) over one-to-one value tokens
  • Design components with a clear props API, defaults, accessibility, and variants
  • Provide migration steps and automated search/replace where possible, then test visually
  • Document usage, examples, and when not to use a component or token

Example use cases

  • Consolidating three different button implementations into a single accessible Button component with primary/secondary variants
  • Turning repeated hard-coded color and spacing values into a semantic token set shared across apps
  • Creating a Card component and migrating multiple ad-hoc card layouts to consume it
  • Standardizing form controls by extracting an Input and Select with consistent validation and focus behavior
  • Adding documented layout patterns (grid, list, detail) to reduce bespoke page-level code

FAQ

What should I extract first?

Start with components and tokens that appear in three or more places or that cause visible inconsistency. Prioritize high-impact UI elements like buttons, inputs, and colors.

How do I avoid over-generalizing components?

Keep components focused: support only necessary variants and sensible defaults. If a use case is truly one-off, leave it out or create a local composition instead of forcing it into the system.