FReptar0/design-guard

為使用 Google Stitch 的網頁專案產生一份完整的 DESIGN.md。

操作說明

0. 探索檢查（必須在執行任何其他步驟之前執行）：
   • 檢查 .dg-research/ 目錄是否存在且包含 JSON 檔案。
   • 若 .dg-research/ 不存在，且使用者已提及特定的商家名稱、公司、品牌、咖啡廳、餐廳、商店或真實世界的實體：
     • 停止。告訴使用者：「我建議先執行 /dg-discover 來研究 [商家名稱]。這樣產生的 DESIGN.md 會基於真實市場與競爭對手資料，而非 AI 預設值。您要我先執行 /dg-discover 嗎？」
     • 僅在使用者明確表示要跳過研究時，才繼續執行 /dg-design。
   • 若 .dg-research/ 存在且包含 JSON 檔案：讀取 .dg-research/latest.json 以取得商家簡報、競爭對手分析與品牌色彩。這些研究資料是您取得商家情境的主要來源——請優先於 CLAUDE.md 中的任何專案層級情境使用。接著進行步驟 1。
   • 若使用者的請求是泛泛的（未提及特定商家，例如「做一個作品集網站」或「建立一個 SaaS 儀表板」）：直接進行步驟 1。研究是針對真實商家，而非泛用型專案。

情境隔離（至關重要——產生前請閱讀）

在產生 DESIGN.md 時，請區分兩種情境：

1. 主機專案 — 您正在其中執行的程式碼庫（Design Guard）。CLAUDE.md 描述的是這個專案。其商業模式、功能、CLI 指令、測試數量與技術架構都關於 Design Guard，而非使用者的目標商家。

2. 目標商家 — 使用者想要取得 DESIGN.md 的商家。這來自：

   • 使用者提供的品牌簡報（步驟 1）
   • .dg-research/latest.json 中的研究資料（若可從 /dg-discover 取得——這是您的主要來源）
   • 關於目標商家的 WebSearch/WebFetch 結果

規則：

• 若目標商家不同於 Design Guard：

  • 不要使用 CLAUDE.md 中的商家描述、功能列表、統計數字或技術細節
  • 不要將 CLI 指令、測試數量、TypeScript、Node.js、MCP 或 Stitch 引用為目標商家的功能
  • 不要將目標商家描述為「開放原始碼」、「設計智慧」或任何來自 CLAUDE.md 專案概覽的詞句
  • DESIGN.md 中的每個商家事實都必須來自使用者的簡報或研究資料
  • 若專案根目錄已有 DESIGN.md，不要將其顏色、字型或商家情境複製到新檔案中——請根據簡報與研究重新產生

• 若目標商家就是 Design Guard 本身：

  • CLAUDE.md 是有效的商家情境來源——請與使用者的簡報一起使用

• 無論目標商家為何，一律遵循 CLAUDE.md 中的 DESIGN.md 8 章節規格與驗證規則。格式規則永遠適用；需要隔離的是商家情境。

1. 若使用者已將品牌簡報作為引數提供，則使用它。否則詢問：

   • 公司/產品名稱
   • 產業或領域
   • 目標受眾
   • 美學方向（例如「高級企業」、「活潑新創」、「極簡 SaaS」）

2. 產生一份包含以下 8 個章節的 DESIGN.md：

   1. 視覺主題與氛圍 — 2-3 句具感染力的句子，描述整體美學。使用具體的形容詞與參考，而非泛用詞彙。
   2. 色盤與角色 — 欄位為「角色、名稱、十六進位色碼、用途」的 Markdown 表格。至少 5 個角色（主要、次要、表面、表面文字、錯誤）。所有顏色必須為十六進位色碼，切勿使用「可信賴的藍色」這類描述。為每個顏色賦予描述性名稱（例如「深海軍藍」而不只是「主要」）。
   3. 字型排版 — 來自 Google Fonts 的字型家族（避免以 Inter、Poppins 作為主要字型——它們代表 AI 生成的設計）。字級單位為 rem/px，字重為數字（400/600/700），行高。包含標題、內文與等寬字型。使用襯線/無襯線配對以營造對比。
   4. 間距與佈局 — 基礎單位（例如 4px）、刻度、最大內容寬度、網格系統、中斷點。
   5. 元件樣式 — 至少 3 個元件（按鈕、卡片、輸入框等），包含結構與樣式規則。變化邊框圓角與陰影樣式。
   6. 圖示 — 樣式（線框/實心/雙色）、預設尺寸、來源庫。
   7. 圖像原則 — 照片風格、插圖風格、長寬比。具體說明圖像傳達的意涵。
   8. 必做與必不做 — 各至少 3 項。必須包含以下這些反抄襲預設值：

   必做

   • 至少為一個功能區塊使用不對稱或非標準佈局
   • 變化卡片尺寸與間距以營造視覺韻律
   • 專門使用指定的色盤（不使用 AI 選擇的顏色）
   • 所有文字維持高對比度（最低 4.5:1）
   • 變化區塊背景（在淺色/深色表面之間交替）

   必不做

   • 不要使用 Inter、Poppins 或系統無襯線字型作為主要字型
   • 不要在任何地方使用紫色到藍色的漸層
   • 不要對所有元素使用統一的邊框圓角（>12px）
   • 不要將標準的三欄圖示網格作為頁面的第二個區塊
   • 不要將超過 2 行的內文置中對齊
   • 不要使用泛用的圖庫插圖（3D 模糊形狀、抽象形狀）

3. 驗證規則：

   • 所有顏色必須為十六進位色碼（#RRGGBB）
   • 字級僅限 rem 或 px
   • 至少 5 個色彩角色、3 個元件樣式、各 3 項必做與必不做
   • 總長度保持在約 3000 個 token 以下（Stitch 會在每次生成時將其作為情境讀取）

4. 若 DESIGN.md 已存在，覆寫前需先詢問。

5. 將檔案寫入專案根目錄的 DESIGN.md。

6. 寫入後，使用 mcp__stitch__list_design_systems 檢查 Stitch 設計系統是否存在。若使用者有 Stitch 專案：

   • 提議使用 mcp__stitch__create_design_system 建立設計系統
   • 或使用 mcp__stitch__update_design_system 更新現有的設計系統
   • 使用 mcp__stitch__apply_design_system 將其套用至專案，以便後續所有生成都能遵循它

7. 下一步：建議執行 /dg-generate 以使用新的設計系統建立第一個畫面。

參考資料：請參閱 docs/design-md-guide.md 以取得完整規格。