Luijaa/web-template

Design: $ARGUMENTS

嚴格按照 docs/design-process.md 的所有步驟進行 — 該檔案是規則，此技能僅負責排序。若與該檔案衝突，以該檔案為準。

1. 是否需要設計 — 與 docs/design-process.md 的表 1（主題 1）進行比對
   • 不需要：用一行說明原因，然後回到 new-feature
   • 不確定：先問人
2. 開始（主題 3.0）：建立 epic issue（標籤 design），分支名 docs/<id>-design-<slug>，複製 docs/design/template.md → docs/design/<slug>.md（system.md 或 <epic 編號>-<slug>.md），設定 status: draft，並在 docs/design/README.md 中新增一行
3. 先讀再問：CONTEXT.md、docs/adr/、docs/architecture.md、docs/design/ 中的其他設計 — 能自己查到的事實自己查，不准問
4. 分輪訪談（主題 3.1）格式 Qn — 主題: 問題 + 每項附 建議: …，每輪 1–2 個邊界案例 — 走完 A–H 分支（主題 3.2），並在核准點 1、2（system）、3 處停下等人
5. 每輪結束後寫入檔案：設計檔案中的章節、CONTEXT.md 中的新詞彙、docs/adr/ 中的 proposed 狀態 ADR（+ 索引），如果容器/外部系統有變更，則更新 docs/architecture.md 中的 C4 圖
6. 檢查（主題 3.3）：make docs-check 必須通過（對於還未包含此目標的儲存庫：python3 <path of web-template>/scripts/check-docs.py <repo> — Hermes 團隊：/home/opc/projects/web-template）+ 自行檢查清單，然後設定 status: proposed
7. 純文件 PR：docs(design): <slug>，內文包含 Refs #<epic>，總結仍未決定的選項，以及 ## CHANGELOG 區塊，內容為 — — 不得包含程式碼，不得合併
8. 核准（主題 3.4）：當核准者提交後，設定 status: approved + approved-by，並在相同的 PR 中將 ADR 改為 accepted（make docs-check 必須通過），然後請人合併
9. 合併後（主題 3.5）：依照主題 13 逐一建立子 issue，每個子 issue 需連結 epic 和設計檔案 — 程式碼工作從 new-feature 開始