home / skills / pbakaus / impeccable / extract

extract skill

/source/skills/extract

This skill helps identify and extract reusable components, tokens, and patterns from your design system to enable systematic reuse.

npx playbooks add skill pbakaus/impeccable --skill 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: 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.
args:
  - name: target
    description: The feature, component, or area to extract from (optional)
    required: false
user-invokable: true
---

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 patterns into your design system to improve consistency and accelerate development. It identifies repetition and inconsistency, then plans, builds, migrates, and documents reusable assets for systematic reuse. The goal is pragmatic, incremental growth of a maintainable component library with clear tokens and usage guidance.

How this skill works

Analyze code and UI to find repeated components, hard-coded values, and inconsistent implementations. Create a focused extraction plan that lists components, tokens, variants, naming, and a migration path. Build accessible, documented components and tokens, run a targeted migration to replace existing instances, and update documentation and catalogs.

When to use it

  • When multiple teams duplicate UI patterns or styles across projects
  • When colors, spacing, or type are hard-coded in many places
  • When you have multiple inconsistent implementations of the same control
  • When onboarding would benefit from a shared component library
  • When preparing a product for scale or cross-platform parity

Best practices

  • Verify an existing design system first; ask before creating a new one
  • Extract only things that are reused or clearly reusable (3+ uses or clear future need)
  • Prefer semantic tokens and meaningful names over one-to-one value tokens
  • Design components with clear props, sensible defaults, and accessibility baked in
  • Plan a migration path: find instances, replace systematically, test visual/functional parity
  • Document components, tokens, patterns, and when not to use them

Example use cases

  • Consolidating three different button implementations into a single accessible Button with size/variant props
  • Turning repeated color and spacing values into a semantic token set for theming
  • Extracting a card layout used across pages into a configurable Card component
  • Standardizing form inputs and validation patterns into a shared Input/Field library
  • Creating layout primitives (Grid, Stack) to replace bespoke spacing implementations

FAQ

What if no design system exists?

Ask stakeholders before creating one; agree on location, conventions, and incremental scope rather than building everything at once.

How do I decide what to extract?

Prioritize items used multiple times, those that improve consistency, and those with reasonable maintenance cost; avoid one-offs.

Should tokens mirror every design value?

No—create tokens that have semantic meaning and real reuse; avoid tokenizing every single value.