@qijenchen/design-system 0.1.0-beta.71 → 0.1.0-beta.73
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/components/AppShell/_demo-helpers.d.ts +3 -1
- package/dist/components/AppShell/_demo-helpers.d.ts.map +1 -1
- package/ds-canonical/fork/governance.lock +106 -2
- package/ds-canonical/fork/launchers/inject_fork_governance_preamble.sh +8 -0
- package/ds-canonical/fork/manifest.json +15 -1
- package/ds-canonical/fork/skills/bug-fix-rhythm/SKILL.md +181 -0
- package/ds-canonical/fork/skills/code-quality-audit/SKILL.md +63 -0
- package/ds-canonical/fork/skills/delivery-handoff/SKILL.md +229 -0
- package/ds-canonical/fork/skills/delivery-handoff/references/flow-diagram.md +180 -0
- package/ds-canonical/fork/skills/delivery-handoff/references/handoff-template.md +177 -0
- package/ds-canonical/fork/skills/delivery-handoff/references/inventory-checklist.md +196 -0
- package/ds-canonical/fork/skills/performance-audit/SKILL.md +107 -0
- package/ds-canonical/fork/skills/product-ui-audit/SKILL.md +230 -0
- package/ds-canonical/fork/skills/product-ui-audit/references/audit-checks.md +246 -0
- package/ds-canonical/fork/skills/product-ui-audit/references/common-misuses.md +329 -0
- package/ds-canonical/fork/skills/product-ui-audit/references/report-template.md +159 -0
- package/ds-canonical/fork/skills/propose-options/SKILL.md +177 -0
- package/ds-canonical/fork/skills/prototype/SKILL.md +244 -0
- package/ds-canonical/fork/skills/prototype/references/audit-checks.md +37 -0
- package/ds-canonical/fork/skills/prototype/references/benchmark-sources.md +94 -0
- package/ds-canonical/fork/skills/prototype/references/checkpoints.md +191 -0
- package/ds-canonical/fork/skills/prototype/references/evaluation-matrix.md +141 -0
- package/ds-canonical/fork/skills/prototype/references/ooux-template.md +198 -0
- package/ds-canonical/fork/skills/prototype/references/proposal-template.md +229 -0
- package/ds-canonical/fork/skills/scan-similar-bugs/SKILL.md +198 -0
- package/ds-canonical/fork/skills/ux-audit/SKILL.md +130 -0
- package/ds-canonical/fork/skills/visual-audit/SKILL.md +245 -0
- package/ds-canonical/fork/skills/visual-audit/output/.gitkeep +0 -0
- package/ds-canonical/fork/skills/visual-audit/references/audit-architecture.md +100 -0
- package/ds-canonical/fork/skills/visual-audit/references/visual-checklist.md +297 -0
- package/ds-canonical/fork/skills/visual-audit/references/world-class-benchmarks.md +198 -0
- package/ds-canonical/hooks/lib/_app_shell_primary_header_consistency.sh +6 -3
- package/ds-canonical/hooks/tests/test_check_app_shell_primary_header_consistency.sh +12 -0
- package/llms-full.txt +1 -1
- package/llms.txt +1 -1
- package/package.json +1 -1
- package/src/components/AppShell/_demo-helpers.tsx +65 -6
- package/src/components/AppShell/app-shell.principles.stories.tsx +11 -0
- package/src/components/AppShell/app-shell.spec.md +32 -0
- package/src/components/AppShell/app-shell.stories.tsx +5 -0
- package/src/components/Avatar/avatar.spec.md +3 -1
- package/src/components/Sidebar/sidebar.spec.md +2 -0
- package/src/patterns/header-canonical/header-canonical.spec.md +5 -4
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: prototype
|
|
3
|
+
description: Build UI prototypes / MVPs via a structured UX workflow — benchmark world-class, evaluate against DS + business, produce 2-3 shortlisted candidates as Storybook explorations, self-audit via product-ui-audit, let stakeholders decide. Invoke via /prototype ONLY when user explicitly uses the words「prototype」「MVP」「原型」 in their message (e.g.「做 prototype」「做 MVP」「做原型」「prototype 一個 X」). **DO NOT auto-invoke on casual phrases** like「怎麼做世界級」「給我幾個方案」「比版本」「比幾個版本」「還能怎麼做」「有哪些選項」— these are ambient conversation / thought-partnering, not explicit skill requests; instead ask「要走 prototype skill 正式流程嗎?還是只想先口頭討論?」to confirm before invoking.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Prototype Workflow
|
|
7
|
+
|
|
8
|
+
Purpose: embody the UX designer's mental model for BUILDING PROTOTYPES — never design by gut; benchmark world-class, filter against DS + business, build multiple shortlisted proposals, self-audit, let stakeholders decide.
|
|
9
|
+
|
|
10
|
+
This skill is the **structured version** of CLAUDE.md Mindset #1「對標世界級」+ #4「真實業務場景」+ #5「猶豫就問」,and the orchestrator for `src/explorations/` folder usage.
|
|
11
|
+
|
|
12
|
+
## When to run
|
|
13
|
+
|
|
14
|
+
**明確觸發**(直接 invoke):user 用「prototype / MVP / 原型」明確字眼。例:「做 prototype」「做 MVP」「做原型」「prototype 一個 X」「做幾個 prototype 版本 compare」。
|
|
15
|
+
|
|
16
|
+
**模糊觸發**(先 clarify):「給我幾個方案」「怎麼做世界級」「有哪些選項」「比版本」 — 多為 thought-partnering,**先問**「要走正式 prototype skill 還是先口頭討論?」
|
|
17
|
+
|
|
18
|
+
**不觸發**:已確定單一 feature(直接 implement)/ 單一 pattern 諮詢(直接答)/ 產品交付(走 `/delivery-handoff`)/ DS 本身稽核(走 `/design-system-audit`)/ consumer UI 檢查(走 `/product-ui-audit`)。
|
|
19
|
+
|
|
20
|
+
**生態位**:`/prototype` → Phase 3.5 chain `/product-ui-audit` gate → stakeholder 決定 → 採用後 `/delivery-handoff`。新 primitive 採用後,加入 DS 時跑 `/design-system-audit` 確保內部健康(正交關注點)。
|
|
21
|
+
|
|
22
|
+
## Preconditions
|
|
23
|
+
|
|
24
|
+
- User has briefed a feature / problem / user need (will be clarified in Phase 0)
|
|
25
|
+
- Working directory is project root
|
|
26
|
+
- CLAUDE.md read fully(DS 既有 primitives / layout primitives 清單 / mindset)
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## 6-Phase Workflow
|
|
31
|
+
|
|
32
|
+
### Phase 0 — Clarify
|
|
33
|
+
|
|
34
|
+
**Input**: user's initial request(可能模糊)
|
|
35
|
+
|
|
36
|
+
**Process**: AI asks user 3-5 targeted questions to lock down:
|
|
37
|
+
- 要做什麼(feature / flow / component)
|
|
38
|
+
- 給誰用(primary user persona)
|
|
39
|
+
- 解決什麼 jobs-to-be-done(具體使用情境,不是 "better UX")
|
|
40
|
+
- 量化指標(若有)(e.g., "減少 50% 流失率")
|
|
41
|
+
- Constraints(mobile-first? accessibility level? 時程?)
|
|
42
|
+
|
|
43
|
+
**Output**: 一段 1-liner summary 確認 alignment。
|
|
44
|
+
|
|
45
|
+
### ⚠️ Checkpoint 0 — User confirms framing
|
|
46
|
+
|
|
47
|
+
User approves the problem framing OR clarifies. Do NOT skip to benchmarking without a clean frame.
|
|
48
|
+
|
|
49
|
+
### Phase 1 — Benchmark research
|
|
50
|
+
|
|
51
|
+
**Input**: Phase 0 framing
|
|
52
|
+
|
|
53
|
+
**Process**: Scan 5+ world-class references. See `references/benchmark-sources.md` for the canonical list of DS + world-class SaaS + industry-specific references.
|
|
54
|
+
|
|
55
|
+
For each reference,收集**兩類資訊**:
|
|
56
|
+
|
|
57
|
+
**A. 視覺 / 互動(表層)**:
|
|
58
|
+
- How do they solve this problem?
|
|
59
|
+
- Screenshot(WebFetch or user provides)
|
|
60
|
+
- Key mechanics:layout / interaction pattern / states / a11y
|
|
61
|
+
- 1-2 line summary of approach
|
|
62
|
+
|
|
63
|
+
**B. OOUX 層(資訊架構深度對標)**:
|
|
64
|
+
- **Core objects** identified(名詞清單 + attributes)
|
|
65
|
+
- **Relationships**(object 間如何連,NOM highlights)
|
|
66
|
+
- **CTAs per role**(key actions each role 對每 object 可做什麼)
|
|
67
|
+
- **UI shape observed**(同一 object 在 list / card / detail / inline 多種 shape 下 attributes 怎麼 progressive disclose)
|
|
68
|
+
|
|
69
|
+
**為什麼加 OOUX 欄**:視覺只看外型會抄到形式,object model 才是 IA 深度。做完 5 家 benchmark 後,你會發現哪些 object 是業界共識 / 哪些命名是該產品獨有 — 這是 Phase 3 自己建 Object Map 的原料。
|
|
70
|
+
|
|
71
|
+
詳細 OOUX 分析方法與範本見 [`references/ooux-template.md`](references/ooux-template.md)「Phase 1 用法」節(內含 Linear issue tracking 完整範例)。
|
|
72
|
+
|
|
73
|
+
**Output**: Markdown scan table(視覺 + OOUX 兩 section):
|
|
74
|
+
|
|
75
|
+
```
|
|
76
|
+
| Reference | Approach | Key mechanics | Screenshot |
|
|
77
|
+
|-----------|----------|---------------|------------|
|
|
78
|
+
| Linear | ... | ... | link |
|
|
79
|
+
| Stripe | ... | ... | link |
|
|
80
|
+
| ... | | | |
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
**Report format**: report back to user as the scan table. Do not advance to evaluation yet.
|
|
84
|
+
|
|
85
|
+
### ⚠️ Checkpoint 1 — Research scope confirmation
|
|
86
|
+
|
|
87
|
+
User reviews the scan. Options:
|
|
88
|
+
- `(a)` Research is sufficient → proceed to Phase 2
|
|
89
|
+
- `(b)` Add references X, Y → extend Phase 1
|
|
90
|
+
- `(c)` Scope changed → restart Phase 0
|
|
91
|
+
|
|
92
|
+
### Phase 2 — Evaluate candidates
|
|
93
|
+
|
|
94
|
+
**Input**: Phase 1 scan table
|
|
95
|
+
|
|
96
|
+
**Process**: for each candidate,score on 4 axes(see `references/evaluation-matrix.md`):
|
|
97
|
+
|
|
98
|
+
| Axis | Scale | Meaning |
|
|
99
|
+
|------|-------|---------|
|
|
100
|
+
| 優缺 | Pros / Cons bullets | 每個候選的獨立評估 |
|
|
101
|
+
| DS 一致性 | 1-5 | 能用多少既有元件 / primitives?新元件要不要造? |
|
|
102
|
+
| 業務 fit | 1-5 | 符合 Phase 0 jobs-to-be-done 多深? |
|
|
103
|
+
| 複雜度 | 1-5(低複雜度 = 5) | 開發成本 / 維護負擔 |
|
|
104
|
+
|
|
105
|
+
**Output**: 評分矩陣 + narrative summary per candidate。
|
|
106
|
+
|
|
107
|
+
Narrative 必含:
|
|
108
|
+
- 對齊 Mindset #1:「我們 vs 這家做法一樣 / 不同的理由」
|
|
109
|
+
- 對齊 Mindset #4:「搭我們的業務情境會不會水土不服」
|
|
110
|
+
- 對齊 Mindset #2:「這個 pattern 我們有對應 primitive 嗎?」
|
|
111
|
+
|
|
112
|
+
### ⚠️ Checkpoint 2 — Shortlist decision(MUST ASK)
|
|
113
|
+
|
|
114
|
+
這是最關鍵的 checkpoint。presenting 評分後,user 決定:
|
|
115
|
+
- 哪 2-3 個候選進 shortlist(要實際做原型)
|
|
116
|
+
- 哪些直接 drop(排除理由寫在 exploration notes)
|
|
117
|
+
- 是否需要混搭(A 的 interaction + B 的視覺 = 新候選 C)
|
|
118
|
+
|
|
119
|
+
**絕對不可**憑 AI 自己評分就挑 shortlist。這是設計決策,stakeholder 要參與。
|
|
120
|
+
|
|
121
|
+
### Phase 3.0 — Build Object Map(ORCA,design 前強制)
|
|
122
|
+
|
|
123
|
+
**Input**: shortlist + Phase 1 benchmark 的 OOUX 分析
|
|
124
|
+
|
|
125
|
+
**Process**: 在寫任何 candidate story 之前,**先做 Object Map**(全體 candidate 共享同一個)。ORCA 4 步:
|
|
126
|
+
|
|
127
|
+
1. **O** Objects:feature 的核心名詞(2-7 個理想;命名三重 test)
|
|
128
|
+
2. **R** Relationships(NOM):object 間關聯(1:1 / 1:many / optional)
|
|
129
|
+
3. **C** CTAs per role:每角色對每 object 的動作清單
|
|
130
|
+
4. **A** Attributes per object:core / metadata / identifying
|
|
131
|
+
|
|
132
|
+
**Output**:`src/explorations/{topic-slug}/notes.md` 增補 OOUX section(見 `references/ooux-template.md`「Phase 3.0」範本 + Step 5 UI Shape → DS 元件映射表)。
|
|
133
|
+
|
|
134
|
+
**為什麼共享同一 Object Map**:3 個 candidate 差異應在 **UI shape + progressive disclosure + CTA ordering**,不在 object 定義本身。若 A candidate 把 Task 拆成 Task + Subtask、B candidate 只有 Task,stakeholder 比稿會變成「比 data model」失焦。除非該 feature 本質就是 data model 辯論,否則 object 定義應一致。
|
|
135
|
+
|
|
136
|
+
**何時跳過**:極小 feature(單一 button / 1-object 開關)可跳過 Phase 3.0,在 notes.md 明文標示「feature 範圍小,跳過 ORCA」。
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
### Phase 3 — Design each shortlisted candidate
|
|
141
|
+
|
|
142
|
+
**Input**: shortlist(2-3 items)+ Phase 3.0 產出的 Object Map
|
|
143
|
+
|
|
144
|
+
**Phase 3.0a — SSOT 5-step pre-check**:寫任何 candidate code 前必過 CLAUDE.md「SSOT 消費 canonical」+ memory `feedback_proactive_5layer_pipeline.md`「5-step pre-check」(SSOT 在 memory + CLAUDE.md,本 skill 不重複)。`check_story_invariants.sh` R1 anatomy(原 check_story_anatomy.sh folded 折入)PreToolUse 是最後安全網,但 5-step 是事前 discipline。
|
|
145
|
+
|
|
146
|
+
**Process**: 每個 candidate 建一個 exploration story,**各 candidate 共享 Object Map 但差異在 UI shape + CTAs 順序**。see `references/proposal-template.md` for structure。
|
|
147
|
+
|
|
148
|
+
目錄結構:
|
|
149
|
+
```
|
|
150
|
+
src/explorations/{topic-slug}/
|
|
151
|
+
├── notes.md # 本 topic 概述 + Phase 2 評估摘要 + 3 候選簡介
|
|
152
|
+
├── {CandidateA}.stories.tsx # 候選 A 原型(Storybook)
|
|
153
|
+
├── {CandidateB}.stories.tsx # 候選 B 原型
|
|
154
|
+
└── {CandidateC}.stories.tsx # 候選 C 原型
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
Storybook title 慣例(不與 Components/ 衝突):
|
|
158
|
+
`Explorations/{Topic}/{CandidateName}`
|
|
159
|
+
|
|
160
|
+
每個 candidate story 必含:
|
|
161
|
+
- 標題說明(candidate 名 + 一句話 positioning)
|
|
162
|
+
- 實際可互動 prototype(用 node_modules/@qijenchen/design-system/src/ 既有元件!)
|
|
163
|
+
- 若需新元件,在 notes.md 標示「此 candidate 需新增 X 元件(若選用此版)」
|
|
164
|
+
- 3 種以上使用場景示範(對齊 Mindset #4 真實業務場景)
|
|
165
|
+
|
|
166
|
+
**DS 一致性鐵律**:
|
|
167
|
+
- 優先用既有 `node_modules/@qijenchen/design-system/src/components/` 元件
|
|
168
|
+
- 若需新元件 / primitive,**notes.md 明文標示**(不偷偷 add 到 components/)
|
|
169
|
+
- 所有 token / layout primitive 按 CLAUDE.md「既有 layout primitives 清單」消費
|
|
170
|
+
|
|
171
|
+
### ⚠️ Checkpoint 3 — 新元件 / primitive 需求
|
|
172
|
+
|
|
173
|
+
若任一 candidate 需要新 DS 元件,**必須 ASK**:
|
|
174
|
+
- 此新元件是本 candidate 獨有?還是跨 candidate 共用?
|
|
175
|
+
- 若被選中,值得升級到 Components/ 嗎?
|
|
176
|
+
- 三重命名 test 過嗎?(見 CLAUDE.md)
|
|
177
|
+
|
|
178
|
+
**絕對不可**在 explorations/ 階段就偷偷 add 到 Components/,會污染 DS。
|
|
179
|
+
|
|
180
|
+
### Phase 3.5 — Self-audit(stakeholder-gate,強制進階 6 維)
|
|
181
|
+
|
|
182
|
+
**Input**: Phase 3 完成 + Checkpoint 3 資源決策完畢的 exploration stories
|
|
183
|
+
**核心原則**:exploration code 不該直接進 Phase 4 給 stakeholder 看 — AI 必先掃 6 維(對齊 CLAUDE.md `# 稽核 canonical` M6:stakeholder-visible 產出 → 強制進階模式)。
|
|
184
|
+
**Output**: per candidate 6 維 report,彙整成 Phase 3.5 gate report。
|
|
185
|
+
|
|
186
|
+
**6 維 + 執行順序 + Gate 規則完整詳細** → `references/audit-checks.md`(SSOT;本 skill 不重複)。重點:
|
|
187
|
+
- D1-D5 chain `/product-ui-audit` / `/performance-audit` / `/ux-audit` / `/visual-audit`
|
|
188
|
+
- D6 chain `principle-audit-protocol.md`(設計原則自檢 4 子維)
|
|
189
|
+
- 前置:M15 Flow snapshot coverage(無 OpenSnapshot story = block audit)
|
|
190
|
+
- Gate 規則:P0 必修 / 高 impact 必修 / D6 疑點 STOP 等 sign-off
|
|
191
|
+
|
|
192
|
+
### Phase 4 — Present & stakeholder decision
|
|
193
|
+
|
|
194
|
+
**Input**: 3 個 exploration stories
|
|
195
|
+
|
|
196
|
+
**Process**: 撰寫 summary(放在 `notes.md`):
|
|
197
|
+
- 每 candidate 一句話重述 positioning
|
|
198
|
+
- 每 candidate 3 個適合場景 / 3 個不適合場景
|
|
199
|
+
- 推薦(AI 可 recommend 一個,但表明 user 決定)
|
|
200
|
+
- Link 到各自 Storybook route
|
|
201
|
+
|
|
202
|
+
**Output**: summary markdown + Storybook URL list → 丟給 stakeholder 評估。
|
|
203
|
+
|
|
204
|
+
### ⚠️ Checkpoint 4 — Final decision & graduation
|
|
205
|
+
|
|
206
|
+
User / stakeholder 決定採用某 candidate 後:
|
|
207
|
+
- `(a)` 採用 A,promote 到 `node_modules/@qijenchen/design-system/src/` 正式(若需新元件)或消費既有元件建正式 UI
|
|
208
|
+
- `(b)` 採用 A 但修改(進第二輪 proposal)
|
|
209
|
+
- `(c)` 混搭 A+B 新 hybrid(新 exploration)
|
|
210
|
+
- `(d)` 全部不採用(保留 explorations/ 作紀錄,也是有價值的 ruled-out)
|
|
211
|
+
|
|
212
|
+
**Graduation 流程**:若升級到正式,在 `explorations/_archive/` 備份 exploration(per CLAUDE.md `# 元件完成 + Exploration`:比稿定案升級 patterns/ 或 components/,舊比稿保留作紀錄),正式 code 進 design-system/。
|
|
213
|
+
|
|
214
|
+
### Phase 5 — Cleanup
|
|
215
|
+
|
|
216
|
+
刪除 drop 的 exploration 或移 `_archive/`。更新 `src/explorations/` 索引。
|
|
217
|
+
|
|
218
|
+
---
|
|
219
|
+
|
|
220
|
+
## Non-goals
|
|
221
|
+
|
|
222
|
+
- 不在 explorations/ 階段做 detail pixel polish(focus 在 pattern 可行性 + 使用者反應)
|
|
223
|
+
- 不自動 promote exploration 到 Components/
|
|
224
|
+
- 不代替 stakeholder 決策(AI 可 recommend,但 flag「需 user / stakeholder 決定」)
|
|
225
|
+
- 不跳過 benchmark 憑直覺造 pattern(違反 Mindset #1 / #2)
|
|
226
|
+
- 不在單個 exploration 塞多個 pattern(一個 story = 一個明確 candidate)
|
|
227
|
+
|
|
228
|
+
## Common failure modes
|
|
229
|
+
|
|
230
|
+
- **Phase 1 太淺**:只看 shadcn / Material 就收工。世界級 SaaS(Linear / Stripe / Notion / Figma)的在地解法才是精華
|
|
231
|
+
- **Phase 2 評分偏誤**:對 DS 一致性加權過低,結果 shortlist 全是「要造 5 個新元件」 — 違反 DRY
|
|
232
|
+
- **Phase 3 太快**:candidate 只做 1 個 story 沒展示多場景 — stakeholder 看不出 robustness
|
|
233
|
+
- **Checkpoint 2 skip**:AI 自己挑 2 個 shortlist 用戶沒過目 → 建完才發現方向全錯
|
|
234
|
+
- **Phase 4 recommend 太強勢**:summary 幫 user「決定」,違反 skill 精神(exploration 就是讓 stakeholder 評估)
|
|
235
|
+
|
|
236
|
+
---
|
|
237
|
+
|
|
238
|
+
## References(`references/`)
|
|
239
|
+
|
|
240
|
+
- `benchmark-sources.md` 世界級對標 + OOUX
|
|
241
|
+
- `ooux-template.md` ORCA / Object Map / NOM / CTA(Sophia V. Prater)
|
|
242
|
+
- `evaluation-matrix.md` 4 軸評分 + 決策規則
|
|
243
|
+
- `proposal-template.md` explorations/ + Storybook 結構
|
|
244
|
+
- `checkpoints.md` 5 MUST ASK 範本 + 歷史 failure mode
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Phase 3.5 Self-audit checklist(/prototype 用)
|
|
2
|
+
|
|
3
|
+
對齊 CLAUDE.md `# 稽核 canonical` M6(stakeholder-visible 產出 → 強制進階模式)。比稿本質是「給 stakeholder 選視覺方向」,6 維任一沒 audit 好就 present = 比稿品質失準。
|
|
4
|
+
|
|
5
|
+
## 6 維對應 skill
|
|
6
|
+
|
|
7
|
+
| 維度 | Skill | Audit scope |
|
|
8
|
+
|------|-------|-------------|
|
|
9
|
+
| **D1 設計語言一致** | `/product-ui-audit` | 6 dim(token 紀律 / layout primitive / 元件使用 / mindset / 幾何 / a11y) |
|
|
10
|
+
| **D2 程式語言一致** | `tsc --noEmit` + lint | exploration 目錄 |
|
|
11
|
+
| **D3 元件效能** | `/performance-audit` | render / memo / bundle(per candidate) |
|
|
12
|
+
| **D4 UX 行為** | `/ux-audit` | keyboard / focus / ARIA / animation |
|
|
13
|
+
| **D5 視覺品質** | `/visual-audit` | Layer A mechanical + Layer B AI judgement |
|
|
14
|
+
| **D6 設計原則自檢(4 子維)** | chain `principle-audit-protocol.md` | 合理 / 一致 / 無矛盾 / 完整 |
|
|
15
|
+
|
|
16
|
+
## 執行順序
|
|
17
|
+
|
|
18
|
+
0. **Flow snapshot coverage 前置檢查**(M15,Phase 3.5 gate 前必過):exploration 必含 OpenSnapshot 類 stories,涵蓋所有 UI flow state(initial / open / confirm / success / error / empty)。Pattern:`defaultOpen` / `useState(true)` / play() interaction 讓 Playwright 能截圖。未提供 = block audit。
|
|
19
|
+
1. `npm run visual-audit -- --scope=component:{topic-slug}`(D5 Layer A,產 snapshots)
|
|
20
|
+
2. Chain `/product-ui-audit`(D1)scope 到 `src/explorations/{topic-slug}/`
|
|
21
|
+
3. Chain `/performance-audit`(D3)scope 到 exploration
|
|
22
|
+
4. Chain `/ux-audit`(D4)scope 到 exploration
|
|
23
|
+
5. Chain `/visual-audit`(D5 Layer B AI judgement)讀 `snapshots/*.png`
|
|
24
|
+
6. **D6 真 scan**:chain `node_modules/@qijenchen/design-system/ds-canonical/skills/design-system-audit/references/principle-audit-protocol.md` 對 exploration code 跑 4 子維;依判斷公式 auto / STOP
|
|
25
|
+
7. **Self-improvement capture**(強制 Phase F step,見 CLAUDE.md `# 治理 canonical`)
|
|
26
|
+
|
|
27
|
+
## Gate 規則(嚴格)
|
|
28
|
+
|
|
29
|
+
| Finding | 處理 |
|
|
30
|
+
|---------|------|
|
|
31
|
+
| D1 / D2 P0(token alias / 硬色 / 幾何違反 / tsc error) | 必修 |
|
|
32
|
+
| D5 Layer A violation(contrast AA 不過 / geometry assertion fail) | 必修(視同 P0) |
|
|
33
|
+
| D3 / D4 高 impact finding(render 爆 / keyboard 不通 / ARIA 缺) | 必修 |
|
|
34
|
+
| D5 Layer B 明顯設計問題 | 必修 OR notes.md 明文 rationale |
|
|
35
|
+
| D6 canonical 疑點 | 不 block,列 STOP 區等 user sign-off |
|
|
36
|
+
| Code P1 > 3 筆 | 建議修,user 可決定先 present 或先修 |
|
|
37
|
+
| 無 P0 + Layer A 乾淨 + D3/D4 無高 impact | 可進 Phase 4 |
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# Benchmark Sources — 世界級對標清單
|
|
2
|
+
|
|
3
|
+
Phase 1 research 的 go-to 資源。**每次 research 至少挑 5 家,跨 DS + SaaS + platform**(不要全抓 component library)。
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Tier 1:Design System 官方文件(規則 + rationale)
|
|
8
|
+
|
|
9
|
+
必掃 — 他們寫出 **why**,不只是 **what**。
|
|
10
|
+
|
|
11
|
+
| DS | 公司 | 強項 | URL |
|
|
12
|
+
|----|------|------|-----|
|
|
13
|
+
| **Polaris** | Shopify | e-commerce UX 完整 / Content guideline 深 | polaris.shopify.com |
|
|
14
|
+
| **Material 3** | Google | 跨平台 / a11y 最完整 / motion spec | m3.material.io |
|
|
15
|
+
| **Atlassian Design System** | Atlassian | enterprise SaaS(Jira/Confluence)/ tone of voice | atlassian.design |
|
|
16
|
+
| **Ant Design** | Ant Group | data-heavy 後台 / form 元件最豐富 | ant.design |
|
|
17
|
+
| **Carbon** | IBM | enterprise / data viz / 大表單 | carbondesignsystem.com |
|
|
18
|
+
| **Apple HIG** | Apple | native macOS/iOS patterns / 手勢 | developer.apple.com/design/human-interface-guidelines |
|
|
19
|
+
| **Primer** | GitHub | dev tools UX / code-adjacent patterns | primer.style |
|
|
20
|
+
| **Base Web** | Uber | mobility / high-density data tables | baseweb.design |
|
|
21
|
+
| **Fluent 2** | Microsoft | enterprise + Windows 11 native | fluent2.microsoft.design |
|
|
22
|
+
| **Spectrum** | Adobe | creative tools / complex forms | spectrum.adobe.com |
|
|
23
|
+
|
|
24
|
+
## Tier 2:Shadcn-style component libraries(實作參考)
|
|
25
|
+
|
|
26
|
+
Shadcn / Radix 為起點,看其他 variants 還做了什麼。
|
|
27
|
+
|
|
28
|
+
| 資源 | 強項 |
|
|
29
|
+
|------|------|
|
|
30
|
+
| **shadcn/ui** | Radix + Tailwind,我們 DS 的起點參考 |
|
|
31
|
+
| **Radix UI** | 無樣式 primitive,a11y / keyboard 最完整 |
|
|
32
|
+
| **React Aria** | Adobe 的 a11y-first hook 集 |
|
|
33
|
+
| **Headless UI** | Tailwind team 出品 |
|
|
34
|
+
| **Chakra** | 成熟 React DS |
|
|
35
|
+
| **Mantine** | 資料密集 components |
|
|
36
|
+
| **Park UI** | Ark UI based,pattern composition 示範 |
|
|
37
|
+
|
|
38
|
+
## Tier 3:World-class SaaS(實際產品 UX)
|
|
39
|
+
|
|
40
|
+
這層是精華 — DS 文件寫不出的 **在地解法**(empty state 怎麼寫 / onboarding 節奏 / 錯誤回饋)。
|
|
41
|
+
|
|
42
|
+
| 類別 | 推薦產品 | 觀察重點 |
|
|
43
|
+
|------|---------|---------|
|
|
44
|
+
| **Project mgmt** | Linear / Jira / Asana / Notion / ClickUp | task states / filter / bulk actions |
|
|
45
|
+
| **Payments** | Stripe / Square / Paddle | form clarity / confirmation flows / error handling |
|
|
46
|
+
| **Design tools** | Figma / Sketch / Adobe XD / Framer | inspector panels / layers / keyboard shortcuts |
|
|
47
|
+
| **Dev tools** | Vercel / Netlify / Railway / Linear | deployments / logs / CLI-to-UI parity |
|
|
48
|
+
| **Communication** | Slack / Discord / Teams / Zoom | DM vs channels / presence / rich composer |
|
|
49
|
+
| **Analytics / Data** | Amplitude / Mixpanel / Datadog / Grafana | chart types / time range / segment filter |
|
|
50
|
+
| **Content** | Notion / Medium / Substack / Ghost | editor UX / share / versioning |
|
|
51
|
+
| **Commerce** | Shopify / Amazon / IKEA / UNIQLO | product listing / checkout / review |
|
|
52
|
+
| **Travel** | Airbnb / Booking / KKday | search / compare / booking flow |
|
|
53
|
+
| **Finance** | Monzo / Revolut / Wise / PayPal | transaction list / security UX / currency |
|
|
54
|
+
|
|
55
|
+
## Tier 4:Platform conventions(OS 慣例)
|
|
56
|
+
|
|
57
|
+
| 平台 | 何時參考 |
|
|
58
|
+
|------|---------|
|
|
59
|
+
| **iOS HIG** | mobile-first / touch gesture / share sheet |
|
|
60
|
+
| **Android Material** | floating action / gesture nav / bottom sheet |
|
|
61
|
+
| **macOS** | menu bar / window chrome / keyboard-first |
|
|
62
|
+
| **Windows 11 Fluent** | tile / acrylic / taskbar interactions |
|
|
63
|
+
| **Web A11y (WCAG)** | keyboard / screen reader / color contrast |
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## 研究步驟
|
|
68
|
+
|
|
69
|
+
每個 reference:
|
|
70
|
+
1. **找到該 feature 的 canonical page / screenshot**(1 張截圖就夠,不要試圖全抓)
|
|
71
|
+
2. **3 個問題**:
|
|
72
|
+
- 他們的核心機制是什麼(layout / interaction / states)?
|
|
73
|
+
- 哪些是「這家獨特」vs「業界共識」?
|
|
74
|
+
- 我們若照做,會 fit 業務嗎(Phase 0 framing)?
|
|
75
|
+
3. **1-2 行 summary** — 避免長 essay,user 會讀 5+ 筆,精簡才 scannable
|
|
76
|
+
|
|
77
|
+
---
|
|
78
|
+
|
|
79
|
+
## 反-patterns(避免 Phase 1 失敗)
|
|
80
|
+
|
|
81
|
+
- ❌ 只抓 3 家相同 DS(`shadcn + Material + Ant`)— 沒有多樣性
|
|
82
|
+
- ❌ 全抓 component library 不看 SaaS 實作 — 漏掉在地解法
|
|
83
|
+
- ❌ 用 AI 描述而非看實物 — 描述容易失真,截圖是真實
|
|
84
|
+
- ❌ 跳過 Platform Tier — mobile / keyboard 盲點多
|
|
85
|
+
- ❌ Tier 3 只看「大公司」— 小而精(Linear / Notion / Vercel)常比大廠創新
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## 截圖取得建議
|
|
90
|
+
|
|
91
|
+
- **WebFetch** 官方 docs / public blog posts
|
|
92
|
+
- **User 提供**(最快 / 最準 — 他們自己用產品)
|
|
93
|
+
- **公開 UX repos**(dribbble / behance — 僅供視覺參考,不等於真實 interaction)
|
|
94
|
+
- 避免 demo videos(長 / 不精準 / 截圖才好比對)
|
|
@@ -0,0 +1,191 @@
|
|
|
1
|
+
# Checkpoints — MUST ASK 時機(skill 內的 user 決策點)
|
|
2
|
+
|
|
3
|
+
5 個不可略過的 checkpoint。past 失敗都因 AI 自行決定了該問的事。
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Checkpoint 0 — Problem framing(Phase 0 後)
|
|
8
|
+
|
|
9
|
+
**格式範本**:
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
🎯 Phase 0 Framing(請確認)
|
|
13
|
+
|
|
14
|
+
問題:{1-liner 重述 user 需求}
|
|
15
|
+
Primary user:{persona}
|
|
16
|
+
Jobs-to-be-done:{具體動機}
|
|
17
|
+
Constraints:{mobile? a11y? 時程?}
|
|
18
|
+
|
|
19
|
+
對嗎?
|
|
20
|
+
(a) 對,進 Phase 1 benchmark
|
|
21
|
+
(b) 以下需修正:...
|
|
22
|
+
(c) 情境不同 — 改: ...
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
**絕對不可**:
|
|
26
|
+
- ❌ 跳過 framing 直接開始 benchmark
|
|
27
|
+
- ❌ 假設 user 的 primary user persona(沒問就 "general user")
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## Checkpoint 1 — Research scope(Phase 1 後)
|
|
32
|
+
|
|
33
|
+
**格式範本**:
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
📊 Phase 1 Benchmark Scan(5+ 家)
|
|
37
|
+
|
|
38
|
+
| Reference | Approach | Key mechanics | Screenshot |
|
|
39
|
+
|-----------|----------|---------------|------------|
|
|
40
|
+
| Linear | ... | ... | link |
|
|
41
|
+
| Stripe | ... | ... | link |
|
|
42
|
+
| Notion | ... | ... | link |
|
|
43
|
+
| ... | | | |
|
|
44
|
+
|
|
45
|
+
上面 N 家研究足夠嗎?
|
|
46
|
+
(a) 足夠,進 Phase 2 評估
|
|
47
|
+
(b) 還想加:___ (指定 tier / 產品)
|
|
48
|
+
(c) 對整個 Phase 0 framing 重新思考
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
**絕對不可**:
|
|
52
|
+
- ❌ 只掃 3 家同 DS 就收工(違反 benchmark-sources.md「至少 5 家跨 tier」)
|
|
53
|
+
- ❌ 直接跳 Phase 2(user 未確認 research 代表)
|
|
54
|
+
- ❌ 抓 demo video / 口述而非 screenshot 或 link(失真)
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Checkpoint 2 — Shortlist decision(Phase 2 後,最關鍵)
|
|
59
|
+
|
|
60
|
+
**格式範本**:
|
|
61
|
+
|
|
62
|
+
```
|
|
63
|
+
🏆 Phase 2 Evaluation
|
|
64
|
+
|
|
65
|
+
{評分表,per evaluation-matrix.md 格式}
|
|
66
|
+
|
|
67
|
+
候選排序:
|
|
68
|
+
- ★ Linear Quick-Filter(14/15)
|
|
69
|
+
- ★ Stripe Step Wizard(12/15)
|
|
70
|
+
- ☆ Notion Command Palette(11/15 邊界)
|
|
71
|
+
- ✗ Atlassian Bulk Popover(8/15 drop 建議)
|
|
72
|
+
|
|
73
|
+
你決定 Phase 3 做哪 2-3 個?
|
|
74
|
+
(a) 採 AI 推薦:Linear + Stripe(2 個)
|
|
75
|
+
(b) 採 Linear + Notion(混 high + 邊界)
|
|
76
|
+
(c) 3 個全做(含 Notion 邊界 candidate)
|
|
77
|
+
(d) 混搭:Linear 的 interaction + Stripe 的視覺 = 候選 D
|
|
78
|
+
(e) Phase 2 評估偏誤 — 重新評估: ...
|
|
79
|
+
(f) 直接 drop 全部 — 回 Phase 0
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
**絕對不可**:
|
|
83
|
+
- ❌ AI 自己 shortlist 不問 user(user 最終 accountability)
|
|
84
|
+
- ❌ 跳過 8 分以下 candidate 的 drop 說明(記入 notes.md 是學習價值)
|
|
85
|
+
- ❌ 擅自「混搭」而沒 surface 為新選項
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## Checkpoint 3 — 新元件 / primitive 需求(Phase 3 中)
|
|
90
|
+
|
|
91
|
+
若任一 candidate 需要**新 DS 元件或 primitive**,必 pause:
|
|
92
|
+
|
|
93
|
+
**格式範本**:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
⚙️ Phase 3 候選「Notion Command Palette」發現新元件需求
|
|
97
|
+
|
|
98
|
+
需要新元件:CommandPalette(全站 Cmd-K query 浮層)
|
|
99
|
+
現有相關 primitive:Command(cmdk 搜尋,內建於 SelectMenu);Dialog(modal 容器)
|
|
100
|
+
|
|
101
|
+
可能路徑:
|
|
102
|
+
(a) CommandPalette 是「Dialog + Command」的 composition,**不需要新元件**,
|
|
103
|
+
建成 explorations/ 內 composition,採用後由 consumer 組合
|
|
104
|
+
(b) CommandPalette 升級為 Components/ 新元件(若跨 candidate / 未來其他場景也需)
|
|
105
|
+
(c) 不做 Notion candidate — 從 shortlist drop
|
|
106
|
+
|
|
107
|
+
你決定?
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
**絕對不可**:
|
|
111
|
+
- ❌ Phase 3 階段偷偷 add 到 Components/(違反 CLAUDE.md 規則分層)
|
|
112
|
+
- ❌ 不 surface 新元件需求(stakeholder 看不到成本)
|
|
113
|
+
- ❌ 混「新 primitive」與「新 variant」(前者 promotion 門檻高,後者在既有元件加)
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Checkpoint 4 — Final decision & graduation(Phase 4 後)
|
|
118
|
+
|
|
119
|
+
**格式範本**:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
🎨 Phase 4 Summary — 3 Candidates
|
|
123
|
+
|
|
124
|
+
## Linear Quick-Filter
|
|
125
|
+
- 適合:sales ops 重度 / PM bulk / support triage
|
|
126
|
+
- 不適合:新手 / mobile fallback 待設計
|
|
127
|
+
- Storybook:Explorations/Bulk Filter/Linear Quick-Filter
|
|
128
|
+
|
|
129
|
+
## Stripe Step Wizard
|
|
130
|
+
- 適合:destructive bulk / 合規 action
|
|
131
|
+
- 不適合:高頻日常
|
|
132
|
+
- Storybook:Explorations/Bulk Filter/Stripe Step Wizard
|
|
133
|
+
|
|
134
|
+
## Notion Command Palette
|
|
135
|
+
- 適合:多維 filter / 可 memory query
|
|
136
|
+
- 不適合:簡單情境 / onboarding 負擔
|
|
137
|
+
- Storybook:Explorations/Bulk Filter/Notion Command Palette
|
|
138
|
+
|
|
139
|
+
AI 推薦:Linear Quick-Filter(業務 fit 最強 + DS 一致性 100%)。
|
|
140
|
+
但最終 stakeholder 決定。
|
|
141
|
+
|
|
142
|
+
你 / stakeholder 決定:
|
|
143
|
+
(a) 採用 Linear,graduate 到 design-system/
|
|
144
|
+
(b) 採用 Stripe,graduate(低頻場景)
|
|
145
|
+
(c) 採用 Notion,討論 Checkpoint 3 新元件決策
|
|
146
|
+
(d) 混 Linear interaction + Stripe visual = 候選 D(新 exploration 輪)
|
|
147
|
+
(e) 全部不採用 — 本問題待定,保留 explorations/ 紀錄
|
|
148
|
+
(f) 更多輪 proposal:修改 A 的 ... / 加新候選
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
**絕對不可**:
|
|
152
|
+
- ❌ AI「幫 user 決定」用哪個(違反 exploration skill 精神)
|
|
153
|
+
- ❌ graduate 採用者但不 archive 其他(未採用也有學習價值,不可刪光)
|
|
154
|
+
- ❌ 跳過「為何沒採用 B / C」的 notes.md 記錄
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
## Checkpoint 5 — Cleanup(Phase 5)
|
|
159
|
+
|
|
160
|
+
決策定案後整理:
|
|
161
|
+
|
|
162
|
+
**格式範本**:
|
|
163
|
+
|
|
164
|
+
```
|
|
165
|
+
🧹 Phase 5 Cleanup
|
|
166
|
+
|
|
167
|
+
採用:Linear Quick-Filter → 已 graduate 到 Components/ 下 ... (或 App-level UI)
|
|
168
|
+
|
|
169
|
+
其他 candidate 處理:
|
|
170
|
+
(a) Stripe Step Wizard → 移 explorations/_archive/(有未來複用潛力)
|
|
171
|
+
(b) Notion Command Palette → 刪除(新元件成本高,短期無計畫)
|
|
172
|
+
|
|
173
|
+
exploration notes.md 更新最終決策理由。
|
|
174
|
+
|
|
175
|
+
確認?
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
**絕對不可**:
|
|
179
|
+
- ❌ 自動刪除未採用 candidate(user 可能有未來計畫)
|
|
180
|
+
- ❌ 不更新 notes.md 最終決策記錄(未來會忘記為何沒選)
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## 歷史 failure mode(作為 anchor)
|
|
185
|
+
|
|
186
|
+
(此 skill 首次建立,尚無 failure 紀錄。將來 skill 使用後踩坑記入此處,如 `design-system-audit` 的 checkpoints.md 歷史段落。)
|
|
187
|
+
|
|
188
|
+
**預期常見失敗**(前人經驗 + 其他 skill 類比):
|
|
189
|
+
- Checkpoint 2 skip:AI 挑 2 個 shortlist 後發現方向錯要從頭
|
|
190
|
+
- Checkpoint 3 忽視:新元件偷偷進 Components/ 污染 DS
|
|
191
|
+
- Phase 1 淺:只掃 3 家同 DS,Phase 2 評估失去對照
|