extract

Overview of extract skill

What extract does

The extract skill helps you turn repeated UI code into reusable design-system assets. In practice, that means finding duplicate components, hard-coded design values, and inconsistent patterns, then proposing or creating shared components and tokens.

Who extract is for

This extract skill is best for teams working on product UIs, component libraries, or Design Systems who already have some code duplication and want a more systematic way to consolidate it. It is especially useful for frontend engineers, design system maintainers, and AI-assisted refactoring workflows.

The real job-to-be-done

Most users are not looking for a generic refactor. They want to answer questions like: “What should become a shared component?”, “Which values should become tokens?”, and “How do we migrate without breaking the app?” The extract skill is oriented around that decision path, not just code cleanup.

What makes this extract skill different

Unlike an ordinary prompt that says “make this reusable,” extract starts from discovery: find the current design system, inspect naming and token conventions, identify repeated patterns, assess whether extraction is actually worth it, then plan the migration. That makes it a better fit for Design Systems work than ad hoc component generation.

When this skill is a strong fit

Use extract when you need to:

• consolidate repeated UI patterns into shared components
• identify token candidates such as colors, spacing, or typography values
• standardize inconsistent variants of the same concept
• enrich an existing design system instead of inventing one from scratch
• plan extraction before editing many files

Important boundary before you install

The biggest adoption constraint is that extract assumes there may already be a design system or shared UI structure to extend. If none exists, the skill explicitly pushes you to ask where and how one should be created before proceeding. If you want greenfield design-system architecture from zero, this skill is only a partial fit.

How to Use extract skill

Install extract skill

Install the skill from the repository with:

npx skills add pbakaus/impeccable --skill extract

After install, invoke it when your task is about extracting reusable UI patterns or tokens rather than building one-off screens.

Know the ideal input before calling extract

The extract skill works best when you provide:

• a target area, feature folder, or set of duplicated files
• the location of your current design system or shared UI library
• the framework and styling stack in use
• the specific reuse problem you want solved
• any migration limits, such as “do not rename public exports”

A vague request like “clean this up” leaves too much guesswork. A better request names the repeated pattern and the destination system.

Turn a rough request into a strong extract prompt

Weak prompt:

• “Refactor these components.”

Better extract usage:

• “Use the extract skill on src/features/billing and src/features/settings to find repeated form-row and card patterns. Our shared components live in src/ui. We use React, TypeScript, and CSS modules. Prefer extracting tokens for spacing and colors only if they appear in 3+ places. Propose a migration plan before editing.”

That prompt gives the skill what it needs to discover, assess value, and avoid over-extraction.

What extract needs to inspect first

Start by pointing the skill at:

• the suspected duplicated UI area
• the shared component directory
• any token or theme files
• existing docs or stories, if present

The source skill emphasizes finding the design system first. That matters because extraction quality depends on matching existing naming, structure, import conventions, and documentation patterns.

Recommended workflow for extract for Design Systems

A practical extract guide looks like this:

1. locate the current design system or shared UI folder
2. scan the target area for repeated components and hard-coded values
3. group similar patterns instead of extracting every visual similarity
4. decide what deserves a shared primitive, composed component, or token
5. propose the extraction plan
6. migrate consuming files carefully

This sequence is the main value of the skill: it reduces premature abstraction.

What to read in the repository first

This skill is lightweight. Read SKILL.md first and treat it as the primary operating guide. The key sections to focus on are:

• Discover
• Plan Extraction
• Extract & Enrich
• Migrate

Because there are no helper scripts or references in this skill folder, most of the real value is in following its decision order correctly.

How extract decides if something should be reused

A good extract install decision depends on whether you agree with the skill’s bias: not everything should be extracted. It is strongest when patterns are used multiple times, likely to recur, semantically stable, and valuable enough to maintain centrally. If your codebase has many one-off marketing layouts, the skill will be less useful.

What output you should expect

A good run of the extract skill should produce some combination of:

• identified component candidates
• token candidates
• consolidation rationale
• a proposed target API or naming scheme
• a migration sequence

If the output jumps straight into code without first confirming where shared assets belong, that is a sign your prompt did not provide enough context.

Practical tips that improve extract usage

To get better results:

• specify the reuse threshold, such as “extract only if used 3+ times”
• name the canonical destination folder
• say whether to preserve current public APIs
• ask for a plan before edits
• separate token extraction from component extraction if the codebase is messy

These details materially change the quality of the extraction plan.

Common misuses of the extract skill

Avoid using extract for:

• net-new component invention with no repeated source pattern
• broad visual redesigns
• full design-system architecture from scratch without stakeholder guidance
• tiny one-file cleanup where no shared abstraction is needed

In those cases, a normal implementation prompt may be faster than the extract skill.

extract skill FAQ

Is extract better than a normal prompt?

For Design Systems work, often yes. A normal prompt may over-abstract quickly or miss the existing system structure. The extract skill is better when the real task is discovering what should be centralized and how to migrate into an established UI system.

Is extract beginner-friendly?

Moderately. The workflow is clear, but beginners may struggle if they cannot identify the design system location, token files, or naming conventions. If you are newer to frontend architecture, provide explicit paths and ask the skill to explain tradeoffs before making changes.

Do I need an existing design system?

Not necessarily, but the extract skill clearly assumes one may exist and tells you to confirm before creating a new system. If your repo has no shared UI layer, use extract mainly for discovery and planning, not autonomous architecture decisions.

What kinds of patterns does extract handle best?

It handles repeated components, hard-coded design values, inconsistent implementations of the same UI concept, and reusable composition patterns. It is less compelling for business-logic refactors that are not tied to reusable UI structure.

When should I not use extract?

Skip extract when the duplicated code is only superficial, when reuse would create a worse API, or when the pattern is too unstable to centralize. Extraction adds maintenance cost, so the skill is most valuable where reuse is durable.

Is extract only for components?

No. The source guidance explicitly includes design tokens and reusable patterns, not just components. That makes extract for Design Systems more useful than prompts that only look for JSX duplication.

How to Improve extract skill

Give extract stronger architectural context

The fastest way to improve extract output is to provide:

• component library path
• token/theme path
• framework and styling stack
• naming conventions to preserve
• migration constraints

Without that context, the skill can still detect duplication, but it cannot place the result cleanly into your system.

Ask for discovery before implementation

If you want higher-quality output, tell the model to use extract in two stages:

1. discovery and recommendation
2. implementation after approval

This reduces the biggest failure mode: extracting too early into the wrong abstraction.

Set a reuse threshold explicitly

One of the best improvements is adding a rule like:

• “Only extract patterns used in 3 or more places”
• “Only create tokens for values repeated across features”
• “Do not centralize one-off layout wrappers”

This helps extract stay aligned with maintainability, not just DRY theory.

Separate component extraction from token extraction

These are related but not identical jobs. If you ask extract to do both at once in a messy codebase, results can get muddled. Better prompts separate them:

• first identify shared components
• then identify token candidates
• then plan migration

That often leads to cleaner output and less churn.

Watch for over-generalized APIs

A common failure mode in extract usage is creating a shared component with too many props just to unify several near-matches. If the proposed API looks more complex than the duplicated code, ask the skill to narrow scope or keep variants separate.

Improve migration quality after the first pass

After the first output, ask follow-up questions such as:

• “Which consumers should migrate first?”
• “What breaks if we replace the old implementations?”
• “Which props or styles should stay local?”
• “Can you propose a compatibility layer?”

This is where extract becomes more than a pattern finder and starts helping with adoption risk.

Use extract with concrete target folders

Instead of “scan the app,” say:

• “Use extract on src/features/checkout against src/components”
• “Review apps/web/src/account for token extraction into packages/ui/tokens”

Concrete scope improves signal, keeps the analysis affordable, and makes the resulting extract plan much more actionable.

Validate that extraction really helps

The best improvement to any extract workflow is asking the skill to justify each proposed abstraction:

• what duplication it removes
• how often it appears
• why the shared API is stable
• why local code would be worse

That simple check filters out clever but low-value extractions.