extract
starsforks
How to install extract?
heyhank-app/heyhank/extract
$npx -y skills add heyhank-app/heyhank --skill extractExtract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library.
SKILL.md
| 1 | Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse. |
| 2 | |
| 3 | ## Discover |
| 4 | |
| 5 | Analyze the target area to identify extraction opportunities: |
| 6 | |
| 7 | 1. **Find the design system**: Locate your design system, component library, or shared UI directory (grep for "design system", "ui", "components", etc.). Understand its structure: |
| 8 | - Component organization and naming conventions |
| 9 | - Design token structure (if any) |
| 10 | - Documentation patterns |
| 11 | - Import/export conventions |
| 12 | |
| 13 | **CRITICAL**: If no design system exists, ask before creating one. Understand the preferred location and structure first. |
| 14 | |
| 15 | 2. **Identify patterns**: Look for: |
| 16 | - **Repeated components**: Similar UI patterns used multiple times (buttons, cards, inputs, etc.) |
| 17 | - **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens |
| 18 | - **Inconsistent variations**: Multiple implementations of the same concept (3 different button styles) |
| 19 | - **Reusable patterns**: Layout patterns, composition patterns, interaction patterns worth systematizing |
| 20 | |
| 21 | 3. **Assess value**: Not everything should be extracted. Consider: |
| 22 | - Is this used 3+ times, or likely to be reused? |
| 23 | - Would systematizing this improve consistency? |
| 24 | - Is this a general pattern or context-specific? |
| 25 | - What's the maintenance cost vs benefit? |
| 26 | |
| 27 | ## Plan Extraction |
| 28 | |
| 29 | Create a systematic extraction plan: |
| 30 | |
| 31 | - **Components to extract**: Which UI elements become reusable components? |
| 32 | - **Tokens to create**: Which hard-coded values become design tokens? |
| 33 | - **Variants to support**: What variations does each component need? |
| 34 | - **Naming conventions**: Component names, token names, prop names that match existing patterns |
| 35 | - **Migration path**: How to refactor existing uses to consume the new shared versions |
| 36 | |
| 37 | **IMPORTANT**: Design systems grow incrementally. Extract what's clearly reusable now, not everything that might someday be reusable. |
| 38 | |
| 39 | ## Extract & Enrich |
| 40 | |
| 41 | Build improved, reusable versions: |
| 42 | |
| 43 | - **Components**: Create well-designed components with: |
| 44 | - Clear props API with sensible defaults |
| 45 | - Proper variants for different use cases |
| 46 | - Accessibility built in (ARIA, keyboard navigation, focus management) |
| 47 | - Documentation and usage examples |
| 48 | |
| 49 | - **Design tokens**: Create tokens with: |
| 50 | - Clear naming (primitive vs semantic) |
| 51 | - Proper hierarchy and organization |
| 52 | - Documentation of when to use each token |
| 53 | |
| 54 | - **Patterns**: Document patterns with: |
| 55 | - When to use this pattern |
| 56 | - Code examples |
| 57 | - Variations and combinations |
| 58 | |
| 59 | **NEVER**: |
| 60 | - Extract one-off, context-specific implementations without generalization |
| 61 | - Create components so generic they're useless |
| 62 | - Extract without considering existing design system conventions |
| 63 | - Skip proper TypeScript types or prop documentation |
| 64 | - Create tokens for every single value (tokens should have semantic meaning) |
| 65 | |
| 66 | ## Migrate |
| 67 | |
| 68 | Replace existing uses with the new shared versions: |
| 69 | |
| 70 | - **Find all instances**: Search for the patterns you've extracted |
| 71 | - **Replace systematically**: Update each use to consume the shared version |
| 72 | - **Test thoroughly**: Ensure visual and functional parity |
| 73 | - **Delete dead code**: Remove the old implementations |
| 74 | |
| 75 | ## Document |
| 76 | |
| 77 | Update design system documentation: |
| 78 | |
| 79 | - Add new components to the component library |
| 80 | - Document token usage and values |
| 81 | - Add examples and guidelines |
| 82 | - Update any Storybook or component catalog |
| 83 | |
| 84 | Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently. |
People who liked this also viewed
6 picksType
- lark-openapi-explorer飞书/Lark 原生 OpenAPI 探索：从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足，需要查找并调用原生飞书 OpenAPI 时使用。SkillsJul 2026
- lark-skill-maker创建 lark-cli 的自定义 Skill。当用户需要把飞书 API 操作封装成可复用的 Skill（包装原子 API 或编排多步流程）时使用。SkillsJul 2026
- azure-cost-optimizationOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026
- vercel-react-native-skillsVercel's official collection of agent skillsSkillsJul 2026
- mcp-builderGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate externaSkillsJul 2026
- gws-sharedgws CLI: Shared patterns for authentication, global flags, and output formatting.SkillsJul 2026
