| name | design-retro |
| description | 分析 docs/design-review-findings.md 歷史，識別跨 spec 的重複 UI 問題模式，提出流程改善建議。spectra-archive 完成或 findings 累積 5 倍數時主動觸發。 |
Design Retro
分析 Design Review 歷史發現，識別跨 spec 的重複問題模式，主動提出流程改善建議。
Prerequisites
本 skill 引用的 /impeccable audit / /impeccable layout / /impeccable harden 等指令來自 pbakaus/impeccable（對齊 design skill Prerequisites 當前鎖定版本，見 design/references/impeccable-install.md）。Consumer 必須先安裝對應版本，否則 retro 報告中的「建議動作」指令會無效。
觸發條件
自動觸發（由 proactive-skills.md 規則驅動）
- Archive 後觸發 —
spectra-archive 完成且該 change 有 design review findings 時
- 累積門檻觸發 —
docs/design-review-findings.md 新增記錄後，總 change 數達 5 的倍數（5、10、15…）
手動觸發
使用者執行 /design-retro 時。可選參數：
/design-retro — 分析全部歷史/design-retro last 3 — 只分析最近 3 個 change
執行流程
Phase 1: 資料收集
- 讀取
docs/design-review-findings.md
- 若檔案不存在或為空 → 回報「尚無 design review 記錄」→ 結束
- 解析所有 change 記錄，建立結構化資料：
- 每筆 finding 的類別、嚴重度、發現來源（哪個 skill 發現的）
- 按 change 時間排序
Phase 2: 模式分析
對收集到的資料執行以下分析：
2.1 頻率分析
按類別統計出現次數與佔比：
| 類別 | 次數 | 佔比 | 趨勢 |
|------|------|------|------|
| spacing | 14 | 30% | ↑ 連續 4 個 change 出現 |
| a11y | 9 | 19% | → 穩定 |
| color | 3 | 6% | ↓ 最近 3 個 change 未出現 |
趨勢判定：
↑ — 最近 3 個 change 中出現 ≥ 2 次→ — 穩定出現但無明顯增減↓ — 最近 3 個 change 中未出現
2.2 嚴重度分析
| 嚴重度 | 次數 | 佔比 |
|--------|------|------|
| critical | 5 | 11% |
| warning | 30 | 64% |
| info | 12 | 25% |
2.3 來源 skill 分析
統計哪個 design skill 發現最多問題：
| 發現來源 | 次數 | 常見類別 |
|---------|------|---------|
| /impeccable audit | 15 | a11y, color |
| /impeccable layout | 10 | spacing, layout |
| /design improve | 8 | consistency |
2.4 熱點頁面分析
統計哪些頁面/元件反覆出現問題：
| 頁面/元件 | 出現次數 | 主要類別 |
|-----------|---------|---------|
| pages/admin/projects.vue | 4 | spacing, layout |
| components/DataTable.vue | 3 | a11y, responsive |
Phase 3: 問題診斷
根據 Phase 2 的數據，診斷根因並分為三個層級：
層級 A：規劃期缺陷（Propose 階段該攔住）
問題在 propose 階段就能預防，但 spec 沒有涵蓋。
判定條件：
- 同類別問題在 ≥ 3 個 change 中重複出現
- 問題屬於可預測類型（spacing、layout、typography、consistency）
改善方向：在 spectra-propose 的 design artifact 加入 checklist
層級 B：實作期缺陷（Apply 階段該攔住）
問題在實作時應該被 skill 攔住，但沒有。
判定條件：
- 問題屬於 hardening 類型（a11y、responsive、hardening）
- 對應的 design skill 未被觸發（如該用 /impeccable harden 但沒用）
改善方向：調整 proactive-skills.md 的 skill 選擇指南或自動觸發條件
層級 C：知識缺口（需要新規則）
問題反映開發者（包括 AI）缺乏某方面意識。
判定條件：
- 問題類型不屬於任何現有
.claude/rules/ 的覆蓋範圍
- 或現有規則不夠具體
改善方向：建議新增或修改 .claude/rules/ 規則
Phase 4: 改善提案
根據 Phase 3 的診斷，產出具體且可執行的改善建議。
輸出格式
# Design Retro — YYYY-MM-DD
## 分析範圍
- 涵蓋 change: [change-1], [change-2], ...（共 N 個）
- 總 findings: M 筆
## 頻率摘要
[Phase 2.1 的表格]
## 診斷結果
### 需要行動的模式
#### 1. [類別] — [問題描述]
- **層級**: A / B / C
- **證據**: 在 [change-x], [change-y], [change-z] 中出現
- **根因**: [為什麼重複發生]
- **建議動作**:
- [ ] [具體的改善行動，例如「在 spectra-propose 的 design artifact template 加入 spacing checklist」]
- [ ] [第二個行動，若需要]
- **預期效果**: [實施後預期減少的問題量]
### 已改善的模式（正向回饋）
- [類別] 從 X% 降至 Y%（自從 [改善措施] 實施後）
### 暫不行動（觀察中）
- [類別]: 出現 N 次，尚未達行動門檻，持續觀察
## 建議優先序
1. [最高優先] — 影響範圍最大 / 嚴重度最高
2. ...
3. ...
Phase 5: 使用者確認與執行
- 將 Phase 4 的提案呈現給使用者
- 逐項詢問使用者是否同意執行（不自動執行）：
- 同意 → 執行對應改動（修改 rules、更新 template、調整觸發條件）
- 不同意 → 記錄原因，下次 retro 不再重複建議
- 延後 → 保留，下次 retro 再提
- 將使用者決策記錄到
docs/design-review-findings.md 尾部的 ## Retro 決策記錄 區塊
Phase 5 決策記錄格式
## Retro 決策記錄
### YYYY-MM-DD
| # | 建議 | 決策 | 備註 |
| --- | ---------------------------- | ------ | ------------------------------- |
| 1 | propose 加 spacing checklist | 同意 | 已更新 spectra-propose template |
| 2 | 強制觸發 /impeccable harden | 延後 | 等累積更多數據 |
| 3 | 新增 a11y rule | 不同意 | 現有 /impeccable audit 已足夠 |
護欄
- NEVER 自動修改
.claude/rules/ 或 skill 檔案 — 所有改動必須經使用者確認
- NEVER 刪除 findings 記錄 — 歷史資料是分析基礎
- 改善建議被使用者拒絕後，同一建議在後續 3 次 retro 內不再重複提出（除非有新證據）
- 若 findings 記錄不足 3 筆 change，只產出頻率摘要，不做診斷和建議（樣本太小）
