- Home
- Skills
- Pbakaus
- Impeccable
- Extract
extract_skill
- JavaScript
10.4k
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill pbakaus/impeccable --skill extract- SKILL.md3.8 KB
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
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.