extract

Overview of extract skill

What extract does

The extract skill helps turn repeated UI code into reusable design-system assets: shared components, design tokens, and standardized patterns. It is built for teams that already have product UI and want to consolidate duplication into something more systematic, not for people looking for a generic brainstorming prompt.

Who extract is best for

extract is most useful for frontend engineers, design-system maintainers, and product teams cleaning up drift across screens or features. It fits especially well when you already suspect the same button, card, form pattern, spacing scale, or color usage appears in multiple places and should be unified.

The real job-to-be-done

The real value of the extract skill is not merely “find duplicates.” It pushes an agent to:

• locate the existing design system or shared UI layer first
• identify patterns that are worth extracting
• avoid premature abstraction
• migrate repeated code into a reusable system with a plan

That makes it more practical than an ordinary “refactor this UI” prompt, especially for extract for Design Systems work where naming, structure, and migration risk matter.

What makes this extract skill different

This skill has a clear workflow: discover the current system, identify extraction candidates, assess whether they are worth systematizing, then extract and migrate carefully. One of its strongest differentiators is a hard guardrail: if no design system exists, it tells the agent to ask before inventing one. That reduces the common failure mode where AI creates an arbitrary component architecture that does not fit the repository.

When to install extract

Install extract if your main need is consolidating repeated UI patterns into an existing or intended design system. If you only need a one-off component built quickly, a direct prompt may be enough. The extract install decision makes sense when consistency, reuse, and migration quality matter more than speed alone.

How to Use extract skill

Install extract skill

A practical install command is:

npx skills add https://github.com/pbakaus/impeccable --skill extract

Because this skill lives at .claude/skills/extract, you do not need to scan the whole repository to get started.

Read this file first

Start with:

• SKILL.md

In this case, SKILL.md is the source of truth. There are no extra scripts, rules, or reference folders surfaced in the repository evidence, so most of the usable guidance is concentrated there.

Know the expected invocation shape

The skill is marked user-invocable and exposes an argument hint of:

[target]

In practice, that means your request should name a concrete target area such as:

• a feature folder
• a page
• a set of components
• a UI surface with repeated patterns

A vague request like “improve our design system” is much weaker than “run extract on src/features/billing and identify reusable form and card patterns.”

Give extract a target, not a broad aspiration

The extract skill works best when the target is bounded. Good targets usually map to one of:

• a directory with duplicated UI
• a product area with visible inconsistency
• a migration from hard-coded styles to tokens
• a cluster of similar components that should become variants

This improves signal because the skill is designed to assess actual reuse opportunities, not to invent abstractions in the abstract.

Turn a rough goal into a strong extract prompt

Weak prompt:

• “Use extract on our app.”

Stronger prompt:

• “Use extract on src/app/settings and src/components/settings. Find repeated controls, hard-coded spacing and color values, and any patterns already close to our shared UI conventions. Propose what should become a shared component or token, what should stay local, and a safe migration order.”

Why this works:

• it identifies the target
• it asks for component and token extraction separately
• it requests a keep-local decision, which reduces over-abstraction
• it asks for migration sequencing, which is critical in real repos

What input materially improves output quality

For better extract usage, provide:

• the location of your existing design system or shared UI folder
• framework and styling stack, such as React, Tailwind, CSS Modules, or styled-components
• naming conventions you already use
• any token source, theme file, or style dictionary
• whether you want proposal-only or actual code edits

Without this context, the agent can still identify repetition, but the extraction plan is more likely to clash with your architecture.

Follow the repository's intended workflow

The skill’s workflow is simple but important:

1. find the design system
2. identify repeated patterns and hard-coded values
3. assess whether extraction is justified
4. extract and enrich the system
5. migrate consumers

That “assess value before extraction” step matters. The skill explicitly warns that not everything should be extracted. A pattern used once or twice may not belong in a shared system yet.

Use extract for Design Systems, not just deduplication

The best use of extract for Design Systems is not deleting duplicate code mechanically. It is deciding what belongs in the system layer versus feature-local code. Ask the skill to classify findings into:

• reusable components
• design tokens
• composition patterns
• local-only code that should remain where it is

That gives you a result you can actually review and adopt.

Ask for a proposal before asking for edits

A practical workflow for adoption:

1. ask extract for findings and candidates
2. review naming, ownership, and migration scope
3. ask for the extraction implementation
4. migrate in small batches

This is safer than asking for immediate edits across the whole app, especially if your current design system is incomplete.

Prompt pattern that usually works well

Use a request like this:

“Use extract on [target]. First locate our existing design system or shared UI directory and summarize its conventions. Then identify repeated components, inconsistent variants, and hard-coded visual values worth turning into tokens. For each candidate, say whether it should be extracted now, deferred, or kept local. After that, propose a migration plan with the lowest-risk order.”

This aligns closely with the skill’s native workflow and tends to produce higher-quality output than generic refactor requests.

Common constraints to decide before running extract

Before using the extract skill, decide:

• can the agent create new shared components, or only propose them?
• should tokens be introduced now or only component consolidation?
• do you want strict backward compatibility?
• can imports and file locations change?

These constraints meaningfully change the recommendation. The skill is much more useful when it knows whether it is planning, implementing, or migrating.

extract skill FAQ

Is extract better than a normal refactor prompt?

Usually yes, if your problem is systematization rather than isolated cleanup. A normal prompt often jumps straight to code changes. extract is stronger when you need the agent to first inspect existing design-system structure, identify what is genuinely reusable, and avoid creating abstractions that the repo cannot support.

Is extract beginner-friendly?

Yes, with a bounded target. A beginner can use the extract skill effectively by pointing it at one feature area and asking for a proposal first. It becomes harder when you ask it to reshape the whole UI architecture without supplying any conventions or boundaries.

Does extract require an existing design system?

No, but it does require a decision. The skill explicitly instructs the agent to ask before creating a new design system if none exists. That is a positive sign for adoption because it avoids silent architecture invention.

When should I not use extract?

Do not use extract when:

• you only need a one-off component
• the UI is too early to justify abstraction
• the pattern appears only once
• you want pixel polish rather than reuse
• there is no agreement on where shared UI should live

In those cases, a simpler prompt or a design decision first will save time.

What kinds of patterns does extract look for?

The skill is oriented toward:

• repeated components
• inconsistent implementations of the same concept
• hard-coded colors, spacing, typography, or shadows
• reusable layout or interaction patterns

That makes it practical for token extraction and shared component work, not just JSX deduplication.

How does extract fit different frontend stacks?

The core logic is stack-agnostic because it is about identifying reuse and system boundaries. Still, output quality depends on you naming the stack and conventions. If your app uses Tailwind, CSS variables, or a component library wrapper, say so up front so the extraction plan matches how your codebase actually works.

How to Improve extract skill

Start with a narrower target than you think

The most common mistake is aiming too wide. Better results come from running extract on one feature, one route group, or one component family first. This gives the agent enough repetition to analyze without forcing premature system-wide architecture.

Tell extract where the design system lives

If you know the shared UI location, say it explicitly:

• src/components/ui
• packages/design-system
• app/shared/components

This reduces guesswork and leads to recommendations that respect existing import, naming, and ownership patterns.

Ask for extraction criteria, not only extraction candidates

A strong improvement prompt is:

• “Use extract, but explain why each candidate should be shared now, later, or never.”

This surfaces the reasoning threshold behind reuse decisions. It helps you avoid a bloated design system full of weak abstractions.

Separate tokens from components in your request

Users often lump all reuse work together. Better output comes from splitting:

• token opportunities: colors, spacing, type, shadows
• component opportunities: buttons, cards, inputs, banners
• composition opportunities: layouts, form sections, repeated assemblies

This makes the result easier to implement and review.

Ask for migration risk and blast radius

One of the biggest adoption blockers is fear of broad regressions. Improve extract usage by asking for:

• affected files or areas
• likely breaking changes
• easy wins versus risky extractions
• a migration order

That turns the first output into something maintainers can approve.

Provide examples of what should stay local

A useful prompt addition is:

• “Keep product-specific or one-off logic local unless reuse is clearly justified.”

This counters a classic AI failure mode: extracting everything that looks similar, even when semantics differ and long-term maintenance would get worse.

Iterate after the first pass

After the first extract guide output, follow up with one of these:

• “Narrow this to only token extraction.”
• “Rework the plan to fit our existing component naming.”
• “Only include patterns used 3+ times.”
• “Convert this proposal into a phased migration checklist.”

The skill improves significantly when you tighten the extraction threshold after seeing initial findings.

Watch for over-abstraction

A common failure mode is inventing highly configurable components where a simpler shared primitive or token would do. If you see proposals with too many props or variants, ask the agent to prefer:

• fewer shared components
• more tokenization
• smaller composition units
• local wrappers where product semantics differ

That usually produces a healthier design system.

Use extract as a decision aid before implementation

For many teams, the best use of the extract skill is diagnostic first, implementation second. Ask it to map opportunities and tradeoffs before writing code. This is especially valuable in legacy codebases, where the wrong abstraction can create more migration work than it saves.

Improve outputs with repository-specific language

If your team uses terms like “primitives,” “recipes,” “slots,” “tokens,” or “foundations,” include that language in the prompt. The extract skill is more useful when it can mirror the vocabulary and structure your maintainers already use, because the recommendations become easier to merge and keep.