design-system

SKILL.md 内容

{
  "name": "design-system",
  "content": "---\nname: Design System\nslug: design-system\nversion: 1.0.0\nhomepage: https://clawic.com/skills/design-system\ndescription: Build design systems with tokens, components, and documentation that scale across teams and products.\nmetadata: {\"clawdbot\":{\"emoji\":\"🎨\",\"requires\":{\"bins\":[]},\"os\":[\"linux\",\"darwin\",\"win32\"]}}\n---\n\n## Setup\n\nOn first use, read `setup.md` for integration guidelines. All preferences are stored in `~/design-system/memory.md`.\n\n## When to Use\n\nUser needs to create, maintain, or extend a design system. Agent handles token architecture, component patterns, documentation structure, and cross-platform consistency.\n\n## Architecture\n\nMemory lives in `~/design-system/`. See `memory-template.md` for structure.\n\n```\n~/design-system/\n├── memory.md         # Status + context + decisions\n└── tokens/           # Token definitions if exported\n```\n\n## Quick Reference\n\n| Topic | File |\n|-------|------|\n| Setup process | `setup.md` |\n| Memory template | `memory-template.md` |\n\n## Core Rules\n\n### 1. Tokens First, Components Second\n\nDesign tokens are the foundation. Before building any component:\n- Define color tokens (semantic, not raw hex)\n- Define spacing scale (consistent multiplier)\n- Define typography scale (modular)\n\nComponents consume tokens. Never hardcode values.\n\n### 2. Semantic Over Literal Naming\n\n| Bad | Good |\n|-----|------|\n| `blue-500` | `primary` |\n| `14px` | `text-sm` |\n| `8px` | `space-2` |\n\nSemantic names survive rebrand. Literal names break everything.\n\n### 3. Three-Tier Token Architecture\n\n```\nPrimitive → Semantic → Component\n   ↓           ↓          ↓\n gray-900   text-primary  button-text\n```\n\n- **Primitive**: Raw values (colors, sizes)\n- **Semantic**: Meaning-based (primary, danger, muted)\n- **Component**: Specific use (button-bg, card-border)\n\n### 4. Document Decisions, Not Just Specs\n\nEvery token and component needs:\n- **What**: The value or pattern\n- **When**: Usage context\n- **Why**: The decision behind it\n- **When NOT**: Anti-patterns to avoid\n\n### 5. Platform-Agnostic Source of Truth\n\nDesign tokens should export to:\n- CSS custom properties\n- Tailwind config\n- iOS/Android native\n- Figma variables\n\nOne source, many outputs. Use Style Dictionary or similar.\n\n### 6. Component API Consistency\n\nAll components follow the same patterns:\n- Same prop naming (`variant`, `size`, `disabled`)\n- Same size scale (`sm`, `md`, `lg`)\n- Same variant names (`primary`, `secondary`, `ghost`)\n\nPredictability beats cleverness.\n\n### 7. Versioning and Migration\n\nBreaking changes need:\n- Version bump (semver)\n- Migration guide\n- Deprecation warnings before removal\n- Codemods when possible\n\n## Common Traps\n\n- **Premature abstraction** → Build 3 instances before extracting a pattern\n- **Token explosion** → 50 grays is not a system, it is chaos\n- **Skipping documentation** → Undocumented patterns get reimplemented wrong\n- **Designing for edge cases first** → Cover 80% well before 100% poorly\n- **No dark mode strategy** → Retrofit is 10x harder than planning upfront\n- **Inconsistent spacing** → Use a scale (4px base), not arbitrary values\n- **Component prop sprawl** → More than 10 props means split the component\n\n## Security & Privacy\n\n**Data that stays local:**\n- Design decisions in ~/design-system/\n- Token definitions and component specs\n\n**This skill does NOT:**\n- Access files outside ~/design-system/\n- Make network requests\n- Store sensitive data\n\n## Related Skills\nInstall with `clawhub install <slug>` if user confirms:\n- `css` — Styling fundamentals\n- `tailwindcss` — Utility-first CSS\n- `frontend` — Frontend development\n- `ui` — User interface patterns\n- `design` — Design principles\n\n## Feedback\n\n- If useful: `clawhub star design-system`\n- Stay updated: `clawhub sync`\n",
  "path": "/home/agentuser/.hermes/skills/design-system/SKILL.md",
  "size": 3741
}