Files
David Ibia ea570af409 feat(omo): retire opencode and move its skills and commands to omo
- Move the vendored skills from .config/opencode/skills to
  .config/omo/skills, with provenance and local changes in its README
- Rewrite Impeccable's script paths to ~/.omo/agent/skills/impeccable so
  its detector and live-server verbs resolve under omo
- frontend-workflow hands screenshots to a visual-engineering task
  instead of opencode run
- Move the notes commands and /impeccable to .config/omo/prompts as omo
  prompt templates; setup-mcp stays behind because it writes
  opencode.json
- Archive DEVELOPMENT-WORKFLOW.md and UI-WORKFLOW.md under
  .config/omo/archive; nothing loads them
- link-ai-configs.sh links the skills into omo and Claude Code only and
  stops linking OpenCode's config, TUI, plugins and workflow docs
- setup-mac.sh and Brewfile.apps stop installing OpenCode; README and
  .withcontextconfig.jsonc follow the new layout

~/.config/opencode/AGENTS.md stays linked: omo's rules engine reads it
before ~/.claude/CLAUDE.md and stops at the first hit, so it carries the
shared preferences and keeps OMC's instructions out of omo.
2026-10-10 14:56:27 +01:00

3.3 KiB

Extract Flow

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

Step 1: Discover the Design System

Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.

CRITICAL: If no design system exists, do not create one yet. STOP and call the question tool to clarify. Understand the preferred location and structure first.

Step 2: Identify Patterns

Look for extraction opportunities in the target area:

  • Repeated components: Similar UI patterns used 3+ times (buttons, cards, inputs)
  • Hard-coded values: Colors, spacing, typography, shadows that should be tokens
  • Inconsistent variations: Multiple implementations of the same concept
  • Composition patterns: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
  • Type styles: Repeated font-size + weight + line-height combinations
  • Animation patterns: Repeated easing, duration, or keyframe combinations

Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.

Step 3: Plan Extraction

Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.

Step 4: Extract & Enrich

Build improved, reusable versions:

  • Components: 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: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
  • Patterns: When to use this pattern, code examples, variations and combinations

Step 5: Migrate

Replace existing uses with the new shared versions:

  • Find all instances: Search for the patterns you 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

Step 6: 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

NEVER:

  • Extract one-off, context-specific implementations without generalization
  • Create components so generic they are 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)
  • Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)