# Design System

> 建立與維護設計系統、Design Tokens、元件規範與文件結構,提升產品一致性與跨團隊協作效率。當任務涉及元件庫、樣式規範、token、文件化、系統治理或跨產品一致性時使用。

- Skill: `candy14432/design-system` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add candy14432/design-system`
- Raw SKILL.md: https://api.skillmd.com/api/skills/candy14432/design-system/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: candy14432 (https://skillmd.com/u/candy14432)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/candy14432/design-system

---


# 設計系統建立法則

## 任務定義

建立可重複使用的設計規則、tokens、元件規範與治理方式,降低不一致與重複建設成本。

## 何時使用

- 產品規模擴大,需要保持一致性時
- 多個團隊協作開發時
- 需要提升設計和開發效率時
- 品牌需要統一視覺語言時

## 必要輸入

- 現有產品畫面、元件或設計檔
- 品牌風格與視覺方向
- 團隊規模與協作模式
- 目前重複問題或不一致問題
- 目標平台與技術棧

## 預期輸出

- 設計系統範圍與原則
- Design Tokens 規劃
- 元件優先順序與規範草案
- 文件架構與治理方式
- 導入與維護建議

## 完成條件

- 已定義設計系統服務的產品範圍、平台與團隊對象
- 已整理核心 tokens、元件優先序與命名原則
- 已說明元件規範、文件架構與治理方式如何協作
- 已辨識短期導入項目與長期維護機制
- 已讓設計與開發團隊可以用同一套規則協作

## 不適用情境

- 只需修單一畫面樣式,不需要完整 design system
- 團隊仍未對產品範圍與核心元件達成基本共識
- 問題主要是單一流程可用性,應先處理 usability-testing 或 wireframing

## 常見誤用

- 把設計系統當成元件展示集,缺少原則與治理
- 一開始就想做太大,沒有先處理最高頻問題
- 只有設計稿規範,沒有對應 token、文件或實作策略
- 元件命名與變體邏輯混亂,導致無法擴充
- 缺乏維護責任與變更流程,讓系統很快失控

## 觸發條件

- 使用者提到「設計系統」、「元件庫」、「design token」、「UI 規範」、「component library」
- 任務需要統一按鈕、表單、色彩、間距或排版規則
- 任務需要把零散畫面整理成可複用的系統

## 高複雜度觸發

- 任務涉及多產品線、B2B 平台、後台模組或多角色共用的複雜系統
- 使用者提到跨團隊協作、元件不一致、不同模組各自發展、缺乏治理機制
- 問題包含權限差異、資料密集介面、複雜表單、狀態不一致或品牌延伸需求
- 團隊不只是要整理視覺,還要建立元件規則、文件與維護流程

## 必要澄清

- 現在最痛的系統性問題是什麼?樣式不一致、元件重複還是跨團隊協作失控?
- 這個設計系統要服務哪些產品、平台與角色?是否包含後台與前台?
- 哪些元件是最高頻且最需要先標準化的?
- 目前是否已經有 token、元件庫、文件站或治理流程?哪些缺口最大?
- 設計與開發團隊如何協作?誰負責審查、發布與維護?
- 這次的目標是建立基礎系統、整併現有元件,還是導入新的治理模式?

## 可搭配技能

- `accessibility-design`: 把無障礙要求納入元件與規範基準
- `wireframing`: 用一致元件快速組裝頁面骨架
- `prototyping`: 驗證元件在真實流程中的互動完整性
- `information-architecture`: 若系統涵蓋大型後台,同步整理頁面與模組結構

## 執行步驟

1. 盤點現況: 找出重複元件、不一致樣式與高頻問題。
2. 定義原則: 先寫清一致性、命名、狀態、無障礙與治理原則。
3. 建立基礎: 定義 colors、spacing、typography、radius、shadow 等 tokens。
4. 排元件優先序: 先做 Button、Input、Select、Card、Table 等高頻元件。

## 執行檢查

- [ ] 已盤點現有元件與樣式不一致問題
- [ ] 已建立核心 tokens 與命名規範
- [ ] 已定義高頻元件優先序
- [ ] 已寫清元件狀態、變體與使用規則
- [ ] 已建立文件與維護流程

## 精簡範例輸出

```markdown
# Design System 核心規格

Tokens:
- primary: #2563EB
- neutral-900: #111827
- spacing-md: 16px
- radius-md: 8px

核心元件:
- Button: primary / secondary / danger
- Input: default / focus / error / disabled
- Card: default / elevated / outlined

治理:
- 新增元件需經設計與前端共同審查
- 變更需附版本記錄與遷移說明
```

## 範例資料庫

本技能提供完整的設計系統範例庫，請參考 `examples.yaml`：

- **Design Tokens**：色彩、字體、間距、圓角、陰影等完整 token 定義
- **元件庫**：按鈕、輸入框、卡片等常用元件的變體和狀態
- **命名規範**：元件、token、變體、狀態的命名慣例
- **文件結構**：元件頁面和 token 頁面的文件組織方式
- **治理流程**：貢獻流程、版本管理、棄用流程
- **實作範例**：CSS Variables、Tailwind Config、React Component 等程式碼範例

使用方式：參考 token 定義建立設計變數，使用元件範例快速建立元件庫。

## 資料使用規則

- 產出內容前，**先閱讀** `TEMPLATE.md`，確認欄位結構、最小必要欄位、品質標準與驗證方式。
- 接著再閱讀 `examples.yaml`，從既有 token、元件規格、命名規範與治理流程中選取最適合的內容。
- 若要新增資料，優先沿用 `TEMPLATE.md` 的格式與命名規則，避免建立重複 token、重疊元件或不一致的治理定義。
- 最終輸出必須優先對齊 `TEMPLATE.md` 的格式要求，其次再引用 `examples.yaml` 的內容細節。