用途：DESIGN.md 是项目视觉语言的单一来源，描述“看起来是什么样”，而非“如何构建”。它集中定义颜色、字体、间距、组件、响应式行为，供构建 UI 的智能体在写代码前阅读并一致应用，避免颜色硬编码、字体与间距在各组件和会话间不一致。
主要能力：采用 Google Stitch 的 9 段式结构，每份 DESIGN.md 必须包含全部 9 段：1 视觉主题与氛围；2 颜色调色板与角色（语义名+十六进制值+功能角色，含深色模式映射）；3 字体规则（字体栈、完整字号表，每级含字号、字重、行高、字距、字体）；4 组件样式（按钮、卡片、输入框、导航等，含 hover、focus、active、disabled 状态与过渡）；5 布局原则（间距刻度、网格、圆角刻度）；6 深度与层级（阴影刻度与表面层级）；7 该做与不该做（含代码示例）；8 响应式行为（断点、触控目标、移动端适配）；9 智能体提示指南（快速参考、使用方式、示例提示、迭代指南）。
设计 token 约定：命名模式为 --{category}-{name}[-{modifier}]，类别包括 color-、space-、text-、radius-、shadow-、font-，可直接映射为 CSS 自定义属性或 Tailwind 配置。
使用方式：智能体在实现 UI 前先阅读 DESIGN.md 或任务中引用的具体段落；实现时使用 token 而非硬编码值；提交信息中注明遵循的段落。kits 的验收标准按段落与 token 名引用，不复制内容；plans 的任务描述包含“Design Reference: DESIGN.md Section {N}”。视觉修复可通过 /ck:revise 回溯并更新对应段落，变更记录到 context/designs/design-changelog.md。可从 awesome-design-md 集合导入 54+ 真实产品设计系统作为起点，导入后即成为项目自有文档。
限制：资料未提供该技能的安装命令、收费与平台信息。质量要求所有值必须具体明确，避免“干净现代”等泛化描述、缺失交互状态、孤立颜色等反模式。