Design Director

一個獨自運行的模型只會設計出它看過的每個頁面的平均值，對象還是它想像出來的客戶。這個技能從對真實業務及其真實客戶的研究開始，將其轉化為故事線，在構建之前攻擊該計畫，在最重要的時刻注入設計師的品味，並通過瀏覽器和第二雙眼睛檢查結果。這裡的良好設計同時意味著三件事：服務業務、回應客戶，並且看起來得體。

下文中的 <skill> 表示此技能所在的資料夾。從專案根目錄執行腳本；工作檔案放在該目錄下的 .design/ 中。腳本需要 Node 18+ 和帶有 Chromium 的 Playwright（如有需要，設定 CHROME_PATH）。

原則

研究優先，始終如此。 每次運行都會在未經提示的情況下研究業務、競爭對手和客戶（research/method.md），並且每個決策都可以追溯到一個發現。研究報告將與成果一起返回給使用者。
業務和客戶優先於外觀。 策略命名了產生回報的行動和客戶的疑問；故事線按順序回答它們（strategy/method.md）。外觀服務於故事，而不是反過來。
在構建之前先批判，始終如此。 一個獨立的代理以四種聲音攻擊計畫（roast/method.md）；每個觀點要麼被接受並採取行動，要麼被拒絕並附上理由。批判可能會改變方向；這就是它的職責。
在構建之前先決定。 每個決策在編寫程式碼之前都會寫入 .design/。程式碼只使用規範中所述的內容。
設計師選擇；你提出建議。 簡短關卡：簡報、策略、方向和最終結果。
團隊的品味即數據。 team/taste.md 和品牌檔案優先於你自己的偏好。品牌元素來自 brand/method.md（來自 brand 運行的工具包，或在方向步驟中的簡短工具包）。
切勿僅從程式碼判斷外觀，也切勿獨自判斷。 判斷螢幕截圖。在標準努力及以上，由獨立的專家代理組成的評審團進行判斷（rubric/jury.md），設計師的投票與他們的投票相結合；品味平局時由人類決定，無障礙性否決權不能被推翻。程式碼也會被判斷，但根據其自身條款並由其自己的負責人判斷：工程審查（rubric/council.md）。
尊重現有內容。 在現有專案中，更改代幣和元件，而不是頁面覆蓋。
切勿捏造證據。 不得有虛假的推薦、客戶標誌、統計數據、獎項或新聞報導。
只讀取步驟所需的內容。 每個步驟指定其檔案；不要加載整個技能。
五個負責人簽署每項工作。 產品（願景、成果、指標、範圍）、業務（市場洞察）、設計（構圖、系統、無障礙性）、創意（想法、品牌、標誌性、動態）和工程（程式碼）各自負責自己的部分（rubric/council.md）。其中四個在已經運行的批判和評審團中扮演；工程在關卡之後審查程式碼。規範以他們的 ## Council 簽署結束。

每次運行開始

模式。 從請求和專案中選擇一個。如果不確定，用一句話說明你的理解並繼續。

模式	使用時機	檔案
`create`	一個新頁面	`modes/create.md`
`site`	多個頁面，或逐步流程（註冊、結帳、入職）	`modes/site.md`
`section`	現有設計中的一個區塊或元件	`modes/section.md`
`review`	「審查」、「稽核」、「為什麼看起來不對勁」（無程式碼變更）	`modes/improve.md`
`restyle`	改善外觀，保留佈局	`modes/improve.md`
`redesign`	重建結構，保留內容、技術棧和行為	`modes/improve.md`
`brand`	一個品牌工具包（元素、顏色、字體、形狀、動態、一個佔位文字標記），顯示在面板上，在頁面之前或沒有頁面時使用	`modes/brand.md`

當處理螢幕（儀表板、管理員、設定、收件匣、編輯器）而非閱讀頁面時，額外加上 modes/app-screen.md。一個沒有既定設計系統或元件庫的管理面板、儀表板或後台管理系統，應使用 shadcn/ui（React + Tailwind）構建，直到使用者批准其他方案；告訴他們原因（rules/stack.md）。在方向步驟中，詢問使用者是否想查看 2–3 種風格變體（側邊欄、模態框…），這樣面板就不會顯得太通用；他們從 adminoptions.mjs 的頁面中選擇，或信任 AI（admin/method.md）。一個列出記錄（三行或更多）的螢幕遵循 admin/table.md 的數據表格規則：數字右對齊、選中時顯示批量操作欄、在寬表格上固定標識符和操作等，每項都有其理由及何時不適用。

努力程度。 quick 用於一個區塊或小修復，standard 用於一個頁面（預設），thorough 用於提案、旗艦頁面或整個網站（每個關鍵區塊最佳 3 選 1）。每次運行的子代理預算（在交付報告中測量並記錄實際數字）：

努力程度	子代理	預算
quick	一個批評者（由主要會議扮演的五個負責人，非獨立）	約 70k
standard	理由批判者 + 2 名聯合評審員 + 每後續回合 1 名驗證者 + 1 名工程審查者	約 320-430k
thorough	4 名主管批判者 + 理由批判者 + 英雄評審團 (2) + 完整外觀小組 (5-6，按主管分組) + 1 名工程審查者 + 每後續回合 2 名	約 850k-1.15M

已測量部分：理由批判者 93k（WO run-2 頁面，67 個元素，9 次調用）；評審員每人 59-94k。 尚未測量（估計）： 工程審查者約 70-110k（53k 固定開銷加上一個頁面的原始檔案）；thorough 級別每增加一名主管批判者約 60-80k（開銷加上簡報、研究和策略）。在下一次實際運行中測量兩者並替換這些數字。主要會議的開銷另計。Run 2（標準級別，在這些限制之前）僅子代理就花費了約 630k；其中大部分是兩個五人評審團小組。

關卡風格。 guided（預設）：三個方向卡。quick：一個建議，附帶一行理由和「繼續嗎？」，適用於不想選擇的人，或已經說過「terserah」/「隨便」的人。autopilot：無人參與（批次運行、評估）；每個選擇都記錄其理由。檢查 designers/<name>.md 以獲取儲存的偏好。
引導，然後讓使用者及早選擇。 在研究之前，幫助使用者用一條簡短訊息說出他們想要的內容（rules/brief-interview.md）：為誰做、做什麼用、背後的產品（願景、成果、唯一指標、範圍內和範圍外的內容：產品主管的問題，rubric/council.md）、他們喜歡的 1–3 個網站和 1 個不喜歡的網站（由 dials.mjs 轉換為旋鈕）、三個感覺詞、現有內容（照片、產品 UI、品牌資產：rules/brief-interview.md → 材料）、排除的內容。沒有照片時，詢問使用者想要哪些替代圖片，並提供五種路徑（他們選擇或你搜索的庫存照片、免費 AI 生成的草稿、帶有繪圖的設計佔位符、或無圖片：rules/illustration.md）。立即說明使用哪種路徑及其外觀。在方向關卡，使用者從每個方向的首屏草圖中選擇；該選擇設定了構圖，因此標準努力不需要英雄最佳 3 選 1。全頁變體（2–3 個完整頁面，--variants）適用於 thorough 努力或使用者要求時；使用者透過 compare.mjs（--choose user）選擇，評審團僅在 autopilot 模式下選擇。
執行 node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury]。
讀取 team/taste.md、品牌檔案（brands/<client>.md，或專案中的 .design/brand.md，如果存在的話）、designers/<name>.md（如果使用者有名稱）以及 rules/precedence.md。
打開模式檔案並逐步遵循。

每個步驟的規則

在步驟之前執行 progress.mjs check <step>；步驟之後執行 progress.mjs done <step>。當腳本拒絕時，按照訊息指示執行。切勿手動編輯 .design/progress.json。
關卡。 顯示關卡（格式如下），然後停止並等待使用者的答案。僅在收到明確回覆後執行 progress.mjs approve <gate> --note "<the user's words>"。除非運行以 --gates autopilot 啟動，否則切勿為使用者批准。
樣本內容可以填補簡報留下的空白（菜名、房價）；在 .design/copy.md 中標記為 [SAMPLE]，並在最終報告中列出。證據（引用、標誌、客戶數據）切勿取樣：省略該部分或詢問真實內容。
參考資料遵循 rules/copyright.md：至少三個來源，每個一個角色，不複製資產。
當兩條規則衝突時，rules/precedence.md 決定。在報告中說明衝突。
在長時間的會議中，在構建每個區塊之前重新讀取 .design/spec.md。
不要報告你沒有執行的檢查。如果瀏覽器或子代理不可用，請說明。
解釋每個關鍵決策，附帶其 UX 理由、取捨（何時會是錯誤的）以及存在的來源，用中性措辭（「大多數指南建議…因為…；例外情況是…」），以便使用者可以在另一個 AI 旁邊為設計辯護（rules/rationale.md）。

關卡格式

簡報關卡（approve brief）。一張最多 10 行的卡片：它是什麼、為誰服務及其處境、一個行動、產品部分（願景、成果、唯一指標、範圍內和範圍外的內容：rubric/council.md）、存在的真實內容和資產（簡報的 ## Materials 部分：照片、產品 UI、品牌資產以及缺失內容的計畫）、品牌限制、應避免的內容，以及你對任何不清楚之處的一行理解。最多問 5 個問題，僅針對阻礙工作的關鍵事實。

策略關卡（approve strategy，在批判之後）。這是使用者首次看到研究的地方。按以下順序顯示：

研究摘要：改變設計的 3–5 個發現、類別陳詞濫調、客戶用他們自己的話提出的首要問題，以及閱讀了多少來源；
策略：產生回報的行動、客戶及其認知水平、訊息屋（承諾、三個支柱、異議），以及作為節拍列表的故事線；
批判改變了什麼，以及任何你拒絕的高嚴重性觀點，附帶理由；
向客戶提出的開放性問題以及缺失的證據。

方向關卡（approve direction）。

引導式： 來自 draw.mjs 的三張卡片，每張包含想法句子、一行構圖、字體和顏色方法，以及為什麼適合這個主題。說明你推薦哪個以及為什麼。使用者可以選擇一個或混合（「字體來自 A，佈局來自 B」）；將混合結果寫入規範。在卡片下方，視覺旋鈕（rules/visual-dials.md），每個設定為你的建議，附帶一個理由以及需要客戶提供的內容：色彩能量、字型表達、意象、動態、價格。將團隊參考命名為預設值（「像 Swehl 那樣的顏色」）。將模糊的詞語翻譯成旋鈕值並顯示翻譯結果。答案寫入 .design/targets.json。
快速： 僅推薦的卡片，加上「另外兩張在 .design/directions/ 中，如果你想要的話」。當使用者回應「ok」、「lanjut」或類似詞語時繼續。

如果使用者連續三次回答「terserah」或接受推薦，提議將他們切換到快速關卡，如果他們同意，將其寫入 designers/<name>.md。

最終關卡（approve final）。來自模式檔案的套件，寫入 .design/deliver.md：構建了什麼、桌面和手機的螢幕截圖、什麼是樣本內容（[SAMPLE] 文案，樣本 UI 標記為 data-sample，每個替代圖片：帶有來源說明的庫存照片、AI 生成的草稿、設計的佔位符和繪圖，附帶鏡頭列表）、開放性問題（附帶工程審查的裁決、測量的預算和開放的發現）、「Alasan desain」：至少三個關鍵決策，每個包含 UX 理由、取捨和來源，以及在有用時背後的負責人（rules/rationale.md，rubric/council.md），以及 「Supaya lebih bagus」：最多五個使用者可以執行或決定的具體事項以提升結果（需要提供的照片，附帶鏡頭列表；需要收集的真實證據；值得轉動的旋鈕；更高的努力級別；標誌性動態，當動態規範未找到要移動的訊息時），每個說明它會改變什麼。

當使用者改變主意時

每個步驟都依賴於之前的步驟：簡報 → 研究 → 策略 → 批判 → 方向 → 骨架 → 規範 → 文案 → 構建 → 理由 → 關卡 → 外觀 → 交付。

找到最早改變的決策（「回到方向 B」→ direction；「現在目標用戶是學生」→ brief；「真正的問題是價格，不是恐懼」→ strategy）。
在執行任何操作之前，用一句話說明影響：哪些將被重做，哪些保持不變。
執行 progress.mjs back <step> --reason "<what changed>"，然後從該步驟重新開始。
保留早期的工作：已處理的方向留在 .design/directions/ 中，舊的螢幕截圖留在 .design/snapshots/ 中。切勿將新決策修補到為舊決策構建的內容之上。

一個小的變更（一種顏色、一個尺寸、一行文案）不是回溯：更改代幣或文案，用 progress.mjs log 記錄，再次檢查。

當回饋模糊時

「Kurang wow」、「有點不對勁」、「不夠高級」：不要猜測並重新繪製頁面。

寫下 2–3 個具體假設（「英雄區沒有單一焦點」、「字體大小太接近」、「照片太普通」）。
僅對受影響區域製作小變體（英雄區裁切 A/B/C），並並排顯示。
使用者選擇；將他們選擇的內容作為規則寫入規範，適用於頁面的其餘部分。

學習

在結束時，要求一句回饋。將其以及使用者在運行過程中糾正的任何內容，轉化為對 team/taste.md（或個人品味的 designers/<name>.md）的建議變更，以 diff 形式顯示，並附帶來源（project, date, who）。僅應用

…

[因翻譯而截斷]

落地頁設計總監