Setup
On first use, read setup.md for integration guidelines. All preferences are stored in ~/design-system/memory.md.
When to Use
User needs to create, maintain, or extend a design system. Agent handles token architecture, component patterns, documentation structure, and cross-platform consistency.
Architecture
Memory lives in ~/design-system/. See memory-template.md for structure.
CODEBLOCK0
Quick Reference
| Topic | File |
|---|
| Setup process | INLINECODE4 |
| Memory template |
memory-template.md |
Core Rules
1. Tokens First, Components Second
Design tokens are the foundation. Before building any component:
- - Define color tokens (semantic, not raw hex)
- Define spacing scale (consistent multiplier)
- Define typography scale (modular)
Components consume tokens. Never hardcode values.
2. Semantic Over Literal Naming
| Bad | Good |
|---|
| INLINECODE6 | INLINECODE7 |
| INLINECODE8 |
text-sm |
|
8px |
space-2 |
Semantic names survive rebrand. Literal names break everything.
3. Three-Tier Token Architecture
CODEBLOCK1
- - Primitive: Raw values (colors, sizes)
- Semantic: Meaning-based (primary, danger, muted)
- Component: Specific use (button-bg, card-border)
4. Document Decisions, Not Just Specs
Every token and component needs:
- - What: The value or pattern
- When: Usage context
- Why: The decision behind it
- When NOT: Anti-patterns to avoid
5. Platform-Agnostic Source of Truth
Design tokens should export to:
- - CSS custom properties
- Tailwind config
- iOS/Android native
- Figma variables
One source, many outputs. Use Style Dictionary or similar.
6. Component API Consistency
All components follow the same patterns:
- - Same prop naming (
variant, size, disabled) - Same size scale (
sm, md, lg) - Same variant names (
primary, secondary, ghost)
Predictability beats cleverness.
7. Versioning and Migration
Breaking changes need:
- - Version bump (semver)
- Migration guide
- Deprecation warnings before removal
- Codemods when possible
Common Traps
- - Premature abstraction → Build 3 instances before extracting a pattern
- Token explosion → 50 grays is not a system, it is chaos
- Skipping documentation → Undocumented patterns get reimplemented wrong
- Designing for edge cases first → Cover 80% well before 100% poorly
- No dark mode strategy → Retrofit is 10x harder than planning upfront
- Inconsistent spacing → Use a scale (4px base), not arbitrary values
- Component prop sprawl → More than 10 props means split the component
Security & Privacy
Data that stays local:
- - Design decisions in ~/design-system/
- Token definitions and component specs
This skill does NOT:
- - Access files outside ~/design-system/
- Make network requests
- Store sensitive data
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
css — Styling fundamentals - INLINECODE23 — Utility-first CSS
- INLINECODE24 — Frontend development
- INLINECODE25 — User interface patterns
- INLINECODE26 — Design principles
Feedback
- - If useful: INLINECODE27
- Stay updated: INLINECODE28
设置
首次使用时,请阅读 setup.md 了解集成指南。所有偏好设置均存储在 ~/design-system/memory.md 中。
使用时机
用户需要创建、维护或扩展设计系统时。代理负责处理令牌架构、组件模式、文档结构以及跨平台一致性。
架构
记忆文件位于 ~/design-system/ 目录下。结构请参考 memory-template.md。
~/design-system/
├── memory.md # 状态 + 上下文 + 决策
└── tokens/ # 导出的令牌定义
快速参考
memory-template.md |
核心规则
1. 令牌优先,组件其次
设计令牌是基础。在构建任何组件之前:
- - 定义颜色令牌(语义化,而非原始十六进制值)
- 定义间距比例(一致的倍数)
- 定义排版比例(模块化)
组件使用令牌。切勿硬编码值。
2. 语义化命名优于字面命名
text-sm |
| 8px | space-2 |
语义化名称能适应品牌重塑。字面名称会破坏一切。
3. 三层令牌架构
原始值 → 语义化 → 组件
↓ ↓ ↓
gray-900 text-primary button-text
- - 原始值:原始数值(颜色、尺寸)
- 语义化:基于含义(主要、危险、柔和)
- 组件:特定用途(按钮背景、卡片边框)
4. 记录决策,而非仅记录规范
每个令牌和组件需要:
- - 是什么:值或模式
- 何时用:使用场景
- 为什么:背后的决策依据
- 何时不用:应避免的反模式
5. 平台无关的单一事实源
设计令牌应导出为:
- - CSS 自定义属性
- Tailwind 配置
- iOS/Android 原生格式
- Figma 变量
一个来源,多种输出。使用 Style Dictionary 或类似工具。
6. 组件 API 一致性
所有组件遵循相同模式:
- - 相同的属性命名(variant、size、disabled)
- 相同的尺寸等级(sm、md、lg)
- 相同的变体名称(primary、secondary、ghost)
可预测性优于巧妙性。
7. 版本控制与迁移
破坏性变更需要:
- - 版本号升级(语义化版本)
- 迁移指南
- 移除前的弃用警告
- 尽可能提供代码转换工具
常见陷阱
- - 过早抽象 → 提取模式前先构建 3 个实例
- 令牌爆炸 → 50 种灰色不是系统,而是混乱
- 跳过文档 → 未记录的模式会被错误地重新实现
- 优先考虑边缘情况 → 先做好 80% 的核心场景,再处理 100%
- 没有暗色模式策略 → 事后改造比预先规划难 10 倍
- 间距不一致 → 使用比例(4px 基数),而非随意取值
- 组件属性泛滥 → 超过 10 个属性意味着需要拆分组件
安全与隐私
本地存储的数据:
- - ~/design-system/ 中的设计决策
- 令牌定义和组件规范
此技能不会:
- - 访问 ~/design-system/ 以外的文件
- 发起网络请求
- 存储敏感数据
相关技能
如果用户确认,使用 clawhub install
安装:
- - css — 样式基础
- tailwindcss — 实用优先的 CSS
- frontend — 前端开发
- ui — 用户界面模式
- design — 设计原则
反馈
- - 如果觉得有用:clawhub star design-system
- 保持更新:clawhub sync