extract
Skill4 starsChanged 6 months agoMITView on GitHub
Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library. Use when the user asks to create components, refactor repeated UI patterns, build a design system, or extract tokens.
37 other projects use a version of this, 14 of them edited.
Adopted by
Most recently taken up by
- kanap-hq/KANAPtheir own version, first seen Nov 8, 2026
- crocotaste/crocotaste-plugintheir own version, first seen Nov 1, 2026
- stoa-platform/stoatheir own version, first seen Nov 1, 2026
- nexmoe/DayBeeedited, first seen Nov 1, 2026
- actionbook/actionbooktheir own version, first seen Oct 25, 2026
- ryneivy/SKILLStheir own version, first seen Oct 20, 2026
Used with
Projects with it also use ai-act-readiness, c-level-agents and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Hussain-ElfalahSkillai-act-readiness
Also in 3 projects that use this
Hussain-ElfalahSkillc-level-agents
Also in 3 projects that use this
MicrosoftSkillinbox-setup
Set up the Inbox agent with recommended VS Code settings and gh CLI configuration
Also in 3 projects that use this
- +9 more from Hussain-Elfalah
Other versions37 projects use a version of this.
Word for word · 7
- talesofai/cohub★ 585100% same
- jagrat7/linux-wallpaper-engine★ 227100% same
- HK-hub/AgentSkills★ 6100% same
- huangzida/skills★ 2100% same
- freshpomelo/agent_skills★ 0100% same
- HAR5HA-7663/Claude-Skills★ 0100% same
- lucaszb-orla/claude-skills★ 0100% same
Edited · 14
- nexmoe/DayBee★ 42498% same
- nexmoe/eve★ 42498% same
- Southclaws/storyden★ 34898% same
- AkaraChen/aghub★ 271100% same
- zacharyfmarion/openscad-studio★ 23896% same
- rwliebs/Dossier★ 8898% same
- heyhank-app/heyhank★ 3496% same
- wpgaurav/WordPress-skills★ 1988% same
- planwiki/planwiki-app★ 996% same
- mtct/skill-editor★ 496% same
4 more not listed
Wrote their own version · 16
- actionbook/actionbook★ 1.6ksame name
- educlopez/ui-craft★ 441same name
- runxhq/runx★ 97same name
- oakreader/oakreader★ 46same name
- cenconq25/claude-code-app-studio★ 40same name
- Hassaan146/claude-skills★ 18same name
- ZenRows/cli★ 16same name
- stoa-platform/stoa★ 9same name
- kanap-hq/KANAP★ 7same name
- Hussain-Elfalah/Agentic-Skills★ 2same name
6 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository37 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adaptSkill
- animateSkill
- arrangeSkill
- auditSkill
- bolderSkill
- clarifySkill
- code-refactorSkill
- colorizeSkill
- critiqueSkill
- delightSkill
- distillSkill
- frontend-designSkill
- gitlab-integrationSkill
- git-operationsSkill
- hardenSkill
- industrial-ai-researchSkill
- latex-paper-enSkill
- latex-thesis-zhSkill
- mermaid-diagramsSkill
- normalizeSkill
- onboardSkill
- optimizeSkill
- overdriveSkill
- paper-auditSkill
- polishSkill
- pydanticSkill
- python-best-practicesSkill
- python-docsSkill
- pytorch-lightningSkill
- quieterSkill
- remotion-best-practicesSkill
- research-paper-writingSkill
- skill-creatorSkill
- teach-impeccableSkill
- typesetSkill
- typst-paperSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. 0 are common, 19 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 28 edited versions we read keep these.
19
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
CRITICAL: If no design system exists, ask before creating one.
- Distinctive: line 22
Identify patterns: Look for:
- Distinctive: line 28
Assess value: Not everything should be extracted.
- Distinctive: line 36
Create a systematic extraction plan:
- Distinctive: line 50
Components: Create well-designed components with:
- Distinctive: line 56
Design tokens: Create tokens with:
- Distinctive: line 61
Patterns: Document patterns with:
- Distinctive: line 62
When to use this pattern
- Distinctive: line 68
Create components so generic they're useless
- Distinctive: line 71
Create tokens for every single value (tokens should have semantic meaning)
- Distinctive: line 77
Find all instances: Search for the patterns you've extracted
- Distinctive: line 78
Replace systematically: Update each use to consume the shared version
- Distinctive: line 79
Test thoroughly: Ensure visual and functional parity
- Distinctive: line 80
Delete dead code: Remove the old implementations
- Distinctive: line 84
Update design system documentation:
- Distinctive: line 86
Add new components to the component library
- Distinctive: line 87
Document token usage and values
- Distinctive: line 88
Add examples and guidelines
- Distinctive: line 89
Update any Storybook or component catalog
“Common” is measured: kept by at least 6 in 10 of the 28 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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:
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.
- 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
- 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

