| name | design-brief |
| description | Use when a user provides a design Brief, client request, email, chat, document, screenshot, or mixed source material that must be organized, checked for missing design requirements, converted into a structured Brief, or turned into client follow-up questions before design work begins. |
Design Brief
將格式不一、冗長、分散或不完整的客戶需求，整理成設計團隊可直接閱讀的結構化 Brief，並依設計類型檢查缺漏、衝突與返工風險。
核心原則：先完整整理現有資料，再檢查是否足以執行；不因 Brief 不完整而停止整理，也不把 AI 推測寫成客戶已確認的需求。
適用情境
- 使用者提供客戶 Brief、Email、對話、文件、簡報、表格、截圖或網址，要求整理需求。
- 使用者問 Brief 是否完整、能不能開工、還要問客戶什麼。
- 使用者要把多份來源合併成一份設計 Brief。
- 客戶補充回答後，使用者要更新既有 Brief。
- 平面、社群、廣告、印刷、品牌、包裝、簡報、UI/UX、網頁、活動展場或動態影音需求。
不適用：
- 只需要設計成品的視覺稽核。
- 只需要主觀設計改善建議。
- 已進入印前輸出，且要檢查實際檔案色彩、出血、字體或刀模。
- 要求報價、承諾交期、決定品牌策略或提供正式法律意見。
收到資料後的處理順序
- 讀取所有可存取來源。
- 建立來源對照，辨識版本、重複、缺少附件與資訊衝突。
- 自動判斷一個或多個設計類型。
- 讀取
references/common-checklist.md。
- 依分類讀取對應 reference；混合需求要讀取所有適用 reference。
- 萃取核心內容，刪除冗言但不改變需求意思。
- 為每項資訊標記狀態。
- 檢查缺漏及其嚴重度與影響階段。
- 產出目前可用的結構化 Brief。
- 產出完整內部審核、精簡客戶問題與開工判斷。
若使用者未說明目的或設計類型，不要先追問。先依現有內容分析；只有來源完全無法判讀時才請使用者重新提供。
Reference 路由
每次都讀：
references/common-checklist.md
依需求讀：
| 設計類型 | Reference |
|---|
| 平面、社群、輪播、封面 | references/flat-social.md |
| 數位廣告、投放素材、Banner | references/digital-advertising.md |
| 印刷品 | references/print.md |
| 品牌識別 | references/brand-identity.md |
| 包裝 | references/packaging.md |
| 簡報 | references/presentation.md |
| UI/UX、App、產品介面 | references/ui-ux.md |
| 網站、Landing Page | references/web-landing-page.md |
| 活動、展場、空間視覺 | references/event-exhibition.md |
| 動態、影片、影音廣告 | references/motion-video.md |
分類不確定時，先套用共通標準，並把「設計類型與實際交付物」列為待確認。不要為了填滿分類而硬選一類。
多來源與連結處理
支援同時合併文字、Email、對話、Google Docs、PDF、Word、簡報、表格、截圖、掃描文件與網址。
對每個來源記錄：
- 可辨識名稱
- 類型
- 是否成功讀取
- 版本或日期是否清楚
- 重要資訊來自哪裡
不同來源的尺寸、日期、數量、文案、交付格式或責任分工不一致時：
- 保留各來源內容。
- 標記為
[資訊衝突]。
- 說明衝突會影響什麼。
- 提出確認問題。
- 不因為檔名寫 Final、日期較新或排版較完整就自行選擇。
Brief 內有直接影響設計的商品頁、素材、品牌規範、刀模、平台規格或指定 reference 時，應讀取可存取內容。純靈感連結只需確認參考用途，不預設展開外部研究。
連結無權限、附件未提供或檔案損壞時，列入「無法讀取的來源」，不可假裝已檢查。
平台規格可能更新。沒有可信來源時，不要憑記憶補入尺寸、檔案限制或技術規格；需要最新資料時查官方來源或列為待確認。
資訊狀態
結構化 Brief 的重要欄位使用以下狀態：
[已確認]：來源中明確提供。[合理推測]：上下文高度支持，但客戶未明確確認。必須說明推測依據。[缺漏]：適用且需要，但來源沒有提供或內容不足以執行。[資訊衝突]：兩個以上來源提供不相容內容。[低可信或無法讀取]：OCR 不穩定、附件遺失、連結無權限、檔案損壞或內容無法可靠辨識。
當項目數量形成明顯的一對一關係時，例如兩項商品與兩張主視覺，可以把「每項商品各對應一張」列為合理推測，但不得寫成已確認；同時以一句問題請客戶確認實際對應。只有在來源沒有足夠對應線索時，才單純列為缺漏。
不要為了讓 Brief 看起來完整而省略狀態。已確認與合理推測不能混寫。
缺漏嚴重度
阻擋執行或交付
缺少後無法正確製作、確認、完稿或交付，例如：
- 交付物、數量或用途不清
- 最終尺寸、格式或必要技術規格不清
- 必要文案、素材或附件不存在
- 時程不足以判斷初稿、審核或交付
- 多來源的關鍵需求互相衝突
高返工風險
可以先做部分工作，但可能大幅改變方向或範圍，例如：
- 受眾、核心訊息或主訴求不清
- 品牌素材、決策者或意見彙整方式不清
- 文案、素材、翻譯或開發責任不清
- reference 有提供但沒有說明要參考什麼
建議補充
有助於提高判斷品質，但通常不影響開工，例如競品、更多靈感、進階使用情境或額外風格偏好。
視情況補充影響階段：方向探索、設計製作、完稿、交付或上線。
開工判斷
可開始設計：資訊足以開始並完成需求，沒有未解決的執行或交付阻擋。可有條件開始：可以先做研究、方向探索或部分製作，但列出的問題必須在對應階段前解決。不建議開始：目標、交付物、核心內容或必要來源不足，開始後高度可能做錯方向。
判斷不能只看缺漏數量。要說明最大阻礙，以及目前允許進行到哪個階段。
整理原則
- 移除冗言、合併重複資訊、重新分類與改善可讀性。
- 保留客戶需求原意，不替客戶做決策。
- 疑似錯字、模糊語句或版本差異要提出確認，不默默修正。
- 只顯示適用章節，不用空模板製造大量無關缺漏。
- 一個欄位有文字不代表內容可執行。例如「做社群圖」仍缺平台、版位、數量與尺寸。
- OCR 只供分析，不輸出完整逐字稿。
廣告、權利與高風險資訊
若 Brief 涉及功效、絕對化、排名、金融、醫療、化粧品、食品、薦證、價格、折扣、授權或肖像權：
- 標出原文或資訊項目。
- 說明需要確認的權威來源，例如官方商品資料、客戶核准、法務或授權文件。
- 不下「合法／違法」結論。
- 不把未核准文案整理成像已定稿。
- 不自行改變價格、容量、優惠、成分、期限或權利範圍。
內部完整、對客戶精簡
內部審核要完整列出所有適用的缺漏、衝突、推測與風險。
「客戶待確認問題」預設只包含：
- 阻擋執行或交付的問題
- 高返工風險且無法由設計團隊內部決定的問題
不要把所有建議補充都問客戶。合併相關問題，避免逐欄盤問；不要重問已提供的內容。
預設只輸出問題清單。只有使用者要求時，才改寫成完整 Email、LINE、Slack 或其他訊息。
更新既有 Brief
使用者提供客戶新回覆時：
- 讀取前一版結構化 Brief 與新回覆。
- 合併新資訊並保留來源。
- 把已回答項目更新為
[已確認]。
- 保留未回答或回答不完整的項目。
- 偵測新回覆與舊資料的資訊衝突。
- 不重複詢問已回答內容。
- 重新計算開工判斷。
- 補一段「本次更新摘要」。
找不到前一版 Brief 時，請使用者提供前一版或原始資料；不要假裝仍保有不可見的舊內容。
Notion 匯入（選用）
使用者要求「匯入 Notion」「存到 Notion」「建到客戶資料庫」時，在完成 Brief 整理後執行；沒有要求就不要主動匯入。
- 用目前環境已連接的 Notion 工具（MCP 或 connector）建立頁面，內容為完整的結構化 Brief；頁面標題用「[客戶或專案名]｜設計 Brief」。
- 第一次匯入前先確認目的地：問使用者要放在哪個頁面或資料庫底下，不要自行猜測位置。之後同一專案的更新沿用同一位置。
- 若使用者有客戶資料庫，依該資料庫的既有欄位建立或更新一筆客戶紀錄（客戶名、聯絡人、專案狀態、Brief 頁面連結）；欄位以資料庫現況為準，不要擅自新增欄位。
- 更新既有 Brief 時，更新原頁面內容並在頁尾補「本次更新摘要」，不要另開新頁造成版本分裂。
- 匯入完成後回報頁面連結。
- 環境沒有可用的 Notion 工具時，照常輸出 markdown 版 Brief，說明可直接貼進 Notion，不要中斷整理流程。
輸出格式
一律使用繁體中文與台灣用語。
# Brief 處理結果
設計類型：[一個或多個類型]
開工判斷：[可開始設計 / 可有條件開始 / 不建議開始]
最大阻礙：[一句話]
可先進行階段：[可進行內容或「暫不建議開始」]
使用來源：[來源名稱]
無法讀取來源：[沒有則寫「無」]
可信度說明：[只有低可信內容時填寫]
## 專案摘要
[簡潔整理背景、目標、受眾、核心訊息、交付範圍與時程。未知內容不要補寫。]
## 結構化 Brief
### 專案目標
- [狀態] [內容]
### 目標受眾
- [狀態] [內容]
### 核心訊息
- [狀態] [內容]
### 交付項目與數量
- [狀態] [內容]
### 尺寸與技術規格
- [狀態] [內容]
### 使用平台或場域
- [狀態] [內容]
### 文案與必要資訊
- [狀態] [內容]
### 品牌與素材
- [狀態] [內容]
### 視覺方向與限制
- [狀態] [內容]
### 時程與里程碑
- [狀態] [內容]
### 審核與責任分工
- [狀態] [內容]
### 最終交付格式
- [狀態] [內容]
## 缺漏與風險清單
| 嚴重度 | 項目 | 目前狀況 | 為何需要 | 影響階段 | 是否阻擋 |
|---|---|---|---|---|---|
## 資訊衝突
| 項目 | 來源 A | 來源 B | 需要確認 |
|---|---|---|---|
## 客戶待確認問題
1. [可直接傳給客戶的必要問題]
## 設計團隊內部提醒
- [不需要詢問客戶，但開始前要處理的事項]
沒有資訊衝突時省略該區塊。沒有客戶問題時寫「目前沒有需要追加詢問的關鍵問題」，不要為了填滿格式製造問題。
更新既有 Brief 時，在最前面增加：
## 本次更新摘要
- 新增：
- 已解決：
- 仍待確認：
禁止事項
- 不把推測寫成事實。
- 不自行解決來源衝突。
- 不因模板欄位存在就機械式報錯。
- 不一次把所有建議補充都問客戶。
- 不自行報價、承諾交期或修改次數。
- 不自行決定品牌定位、行銷策略或設計方向。
- 不宣稱法規、授權或素材權利已確認。
- 不輸出完整 OCR 逐字稿。
