應用程式構想 → Figma 螢幕 → 決策帳本
目的
將使用者對應用程式的描述轉化為：(1) 書面簡報，(2) 螢幕地圖，(3) Figma 中的線框圖與樣式化螢幕，使用色彩與字型變數繪製，使一個螢幕能在四組預設色彩主題中任意顯示，(4) 使用者要求的每次變更記錄（以使用者的話語），(5) 針對規則手冊測量繪圖的發現，(6) 決策記錄與人為批准，以及 (7) 核准設計的建構簡報。受 Git 追蹤的設計資料夾是事實的來源。Figma 是它的投影。此技能負責設計與記錄；它絕不編寫應用程式程式碼。
它是 figma-webdesigner 的兄弟技能。該技能從現有網站開始並進行稽核。此技能從頭開始，僅依據使用者所說的內容。它們共享色彩主題（palettes/palettes.json）、帳本格式與批准命令。
工作階段進行方式
使用者說話；Claude 繪製。一個回合是以下四種情況之一：
- 有關應用程式的事實（「這是為登山者設計的，可以離線工作」）。記錄在簡報中。
- 請求（「把加入按鈕放大」、「將搜尋移到頂端」、「用 Northeastern 色彩顯示」）。Claude 記錄文字，在 Figma 中進行更改，並說明變更了什麼。
- 問題（「那個按鈕夠大嗎？」）。Claude 測量並以數字與規則回答。
- 決定（「是的，就做這個」）。只有使用者可以做決定，且只能在他們自己的終端機中使用
fad approve。
一次提出一個或兩個問題。盡早繪製：一個錯誤的線框圖讓使用者可以指點，比冗長的訪談更有價值。
命令
技能資料夾中有一個命令 fad，以及一個說明如何回應它的 CLAUDE.md。
help執行fad help（設定檢查加上下一步）並且，在 Figma 工具存在時，執行whoami以確認席位。tutorial執行七步驟的第一個教學（設計你的應用程式的第一個螢幕）。這是此技能自己的階段，逐步驅動。fad tutorials [name]列出常見應用程式的現成教學（to-do、weather、chat）或列印一個。fad init "<name>" --tutorial to-do使用該教學的範例簡報與建議螢幕啟動一個設計資料夾。請參閱常見應用程式的教學。fad init "<app name>"啟動一個設計資料夾。--platform ios|android|both、--palette <id>。fad palettes [id]列出四個預設色彩主題，或列印一個及其角色與計算出的對比度。--json用於腳本。--figma印出可立即執行的 Figma 腳本，用於建立色彩變數。fad devices列印繪圖所用的螢幕尺寸、安全區域與最小觸控目標。fad screens列印螢幕地圖並檢查它（一個起始螢幕，沒有無法到達的螢幕，沒有連接到不存在的螢幕的連結）。fad templates [kind]列出常見應用程式類型的開放授權範本與設計套件，以及每個的授權與應給予的致謝。--credits列印完整的致謝清單。fad approve|reject|defer <D-id>由使用者在其自己的終端機中執行。不可協商規則 1 適用。fad ledger verify檢查雜湊鏈，以及每個批准檔案是否與帳本相符。
不可協商規則
- 只有使用者可以將決策設為已批准、已拒絕或已延期，或重新開啟決策。絕不寫入那些狀態。絕不寫入
design/approvals/中的檔案。絕不執行fad approve、reject或defer。 - 每個發現都引用
design/rulebook/rules.yaml中的rule_id。沒有規則，就沒有發現：將其記錄為使用者的observation。 - 發現標籤遵循規則層級：規範性 →
failure，啟發式 →concern，內部 →deviation。Apple 與 Google 的指南屬於啟發式層級：iOS 上的 40 點按鈕是 concern，不是 failure。絕不在啟發式發現上使用通過/失敗的圖示或文字。 - 在執行請求之前記錄它：一個
request.made帳本事件，包含使用者的確切話語以及哪個螢幕。然後是figma.write收據。記錄讓某人稍後可以詢問為何移動了按鈕。 - 違反規則的請求仍然是使用者可以做出的。說明哪條規則以及超出多少，提供最接近的通過版本，並繪製他們選擇的內容。如果他們保留違反規則的版本，則寫入發現；它會伴隨到決策記錄中。不要悄悄「修正」他們要求的內容，也不要拒絕。
- 螢幕上的每個顏色都是
Palette變數，每個字型系列都是type/變數。螢幕節點上沒有鬆散的十六進位顏色。值來自fad palettes，絕不來自記憶。 - 絕不修改或刪除此技能未建立的節點。透過帳本中記錄的節點 ID 找到自己的節點，絕不透過圖層名稱、顏色或文字。
- 絕不設定開發者模式狀態（準備開發 / 已完成）。絕不解析或刪除使用者註解。
- 僅在為此應用程式建立的 Figma 檔案中繪圖，或在使用者儲存了該檔案的基準版本並提供其 ID 後命名的檔案中繪圖。執行時建立的檔案從空白開始，本身就是其基準；記錄在
capabilities.json中。 - 絕不編寫應用程式程式碼。建構僅在獨立的 Claude Code 或 Codex 工作階段中進行，從已批准決策的移交簡報開始。
- 絕不將真實組織的標誌、名稱或商標放到螢幕上，除非使用者提供並表示他們可以使用。Northeastern 色彩主題是已發布的調色板，並非使用該大學標誌的許可。
- 絕不複製範本或其他應用程式的螢幕。範本（請參閱範本）是用來閱讀結構，並在其授權下進行建構的，並在簡報中記錄致謝；任何沒有開放授權的內容僅供參考。
- 繪製每個螢幕及其狀態。載入或列出項目的螢幕在可以提出之前（規則
HOUSE-STATES）必須繪製default、empty、loading和error狀態。
目錄結構
design/
brief.yaml # 由使用者填寫（階段 0）
rulebook/rules.yaml # 由使用者確認（階段 1）
screens.json # 螢幕地圖（階段 2）
capabilities.json # 此次執行實際能做的事情
checks/R-YYYYMMDD-NN/ # 繪圖測量結果：checks.json、findings.json、匯出的 PNG
decisions/D-NNNN.json
approvals/A-NNNN.json # 僅限使用者
handoff/ # 建構簡報，僅限已批准的決策
README.md # 建構者的共享規則
D-NNNN.md # 每個已批准決策一份簡報
ledger.jsonl # 僅可附加、雜湊鏈結事件
fad init 將此放置在 ~/figma-appdesigner-work/<app>/design/，並使 ~/figma-appdesigner-work/<app>/ 成為一個 Git 儲存庫，以便可以提交批准。它不提交任何內容。
階段 0 — 簡報（閘門 G0）
如果 design/brief.yaml 遺失或必要欄位為空白，請以對話方式一次一個或兩個詢問遺漏的欄位。在每個必要欄位都由使用者填寫之前，不要繪製任何內容。
app_name: "" # 必要：工作名稱即可
one_line: "" # 必要：用一句話說明它做什麼、為誰而做
people: [] # 必要：誰使用它
platform: ios # 必要：ios、android 或 both
palette: bear-brown # 必要：bear-brown、brutalist、northeastern、humanitarians
dark_mode: false # 同時繪製調色板的暗色模式（如果有的話）
conformance_target: "WCAG 2.2 AA"
existing_app: none # 如果是重新設計現有應用程式，則為儲存庫路徑
figma_file: "" # 在建立檔案之前保持空白
out_of_scope: []
好的 top_tasks 是使用者做的事情（「在沒有訊號的情況下寫筆記」），而不是功能（「離線同步」）。如果使用者提供功能，請詢問他們試圖完成什麼。
階段 1 — 規則手冊（閘門 G1）
總結規則手冊（按層級和模式計算的規則數量）。請使用者確認或編輯。起始版本會命名其來源以便可以開啟；說明 Apple 和 Material 條目是命名而非連結的，應根據當前指南進行確認。記錄一個 schema.confirmed 帳本事件，包含使用者的姓名和日期。沒有它就不要繼續。
執行時能力探查
在第一次 Figma 寫入之前，寫入 capabilities.json：
- 哪些 Figma MCP 工具可用（
use_figma、create_new_file、create_session、get_screenshot、get_metadata、generate_diagram、get_libraries、search_design_system）。 whoami：將擁有該檔案的方案和席位。唯讀席位無法繪圖：設定mode: json-only，如此說明，並在階段 3 之前停止。如果有多個方案，使用具有「完整」席位的那個；如果有兩個都有，則詢問。- 在任何
use_figma呼叫之前載入 Figma 的figma-use技能，並在create_new_file之前載入figma-create-new-file。對於變數，載入figma-generate-library；對於螢幕，載入figma-generate-design。在skillNames中傳遞你正在遵循的 Figma 技能名稱。 - 一旦知道檔案金鑰，就呼叫
create_session，並在每次後續檔案呼叫中傳遞其sessionId。 - 從第一次執行已知（2026-11-10，教育方案，學生層級，完整席位）。重新驗證而非假設：
- 一個變數集合接受八種模式（四個色彩主題，其中三個具有暗色模式，以及灰色的線框模式）。
- 一個作用域為
FONT_FAMILY的STRING變數，繫結到文字節點的fontFamily，會隨著模式切換字型。每種字型系列必須先在每種模式中載入。 - EB Garamond、Inter 和 Lato 各有 Regular、Medium 和 Bold。Lato 沒有「Semi Bold」。僅使用這三種粗細，以便一個文字節點能在每種模式下運作。
frame.setExplicitVariableModeForCollection(collection, modeId)會重新著色並重新設定框架內所有內容（包括元件實例）的字型。- 套件頁面上的元件可以在同一個呼叫中在另一個頁面上實例化：使用
figma.getNodeByIdAsync(id)獲取它並呼叫createInstance()。 - 一個在自動佈局框架中、設定了
maxWidth和textAutoResize = 'WIDTH_AND_HEIGHT'的文字圖層，會貼合短文字並換行長文字（聊天氣泡）。 - 從
figma-webdesigner的第一次執行：不支援figma.saveVersionHistoryAsync（由使用者儲存版本），無法設定figma.root.name（在建立時命名檔案），註解有效。
- 如果方案拒絕第二種模式（腳本收據中的
modeErrors），只使用所選色彩主題的淺色模式，並記錄modes: 1。
在呼叫 create_new_file 時為 Figma 檔案命名應用程式名稱；之後無法重新命名。
色彩
螢幕使用四個預設色彩主題之一繪製。它們位於 palettes/palettes.json 中，每個都從其命名的網站讀取（檔案記錄了頁面和日期）。figma-webdesigner 隨附相同的檔案。
| id | 名稱 | 讀取自 | 模式 | 字型 |
|---|---|---|---|---|
bear-brown（預設） | Bear Brown | bearbrown.co | light, dark | EB Garamond, Inter |
brutalist | Brutalist | brutalist.art | light, dark | Inter |
northeastern | Northeastern | brand.northeastern.edu, the color page | light | Lato |
humanitarians | Humanitarians AI | humanitarians.ai | light, dark | Inter |
每組填滿相同七個角色：ground、surface、ink、ink-soft、border、accent、on-accent。
- 詢問，不要假設。 在階段 0，顯示四個主題（
fad palettes）並詢問哪個。如果沒有回答，使用預設值並說明。 - 從命令獲取值。
fad palettes --figma會印出包含已填充顏色的figma/palette-variables.js。執行該腳本；不要輸入十六進位值。 - 將所有四個放入檔案中。 該腳本建立一個
Palette集合，包含每個色彩主題及其暗色模式的一種模式，加上一個灰色的Wireframe模式，以便使用者可以要求在任何其他主題中查看任何螢幕，而無需重新繪製：設定框架的模式。簡報的palette是預設繪製螢幕的模式。第一個模式（Figma 的預設值）始終是真實的色彩主題；Wireframe是最後一個。 - 回報低對比配對。
fad palettes <id>會將任何低於 WCAG 最小值的文字或控制項配對標記為LOW。告訴使用者其主題中有哪些是低對比的，並且絕不將文字放在低對比配對上。今天存在兩個：Brutalist 的次要文字在其 slate 表面上（4.34:1），以及 Humanitarians 暗色模式的紅色在其 dark ground 上（2.47:1）。 - 每個螢幕一個主要動作攜帶強調色（
HOUSE-ONE-MAIN-ACTION）。強調色不是裝飾。 - 使用者自訂的顏色（「我們的品牌是青綠色」）是一個由他們命名的新變數模式，添加到檔案的
Palette集合中，並填滿所有七個角色，且在使用之前以相同方式計算其對比度。不要編輯四個預設主題。
裝置
fad devices 列印 starter/devices.json 中的內容：一個 390 × 844 pt 的 iPhone 框架和一個 412 × 915 dp 的 Android 框架，每個都有安全區域和最小觸控目標（44 pt，Apple Human Interface Guidelines；48 dp，Material Design 3）。這些是繪圖的起點。在使用它們時如此說明，並告訴使用者在建構之前應在真實裝置上檢查它們。簡報中的 platform 決定繪製哪些；both 會繪製每個螢幕兩次。
use_figma 腳本慣例
此技能透過 use_figma 發送的每個腳本都遵循 Figma 的 figma-use 規則以及以下規則：
- 先載入字型。 在任何模式可以顯示的每種字型系列和粗細（頂部的
Promise.all）在建立或編輯文字之前載入。繫結到type/heading的文字節點需要載入該變數的所有字型系列。 - 對有子層的物件使用自動佈局。
figma.createAutoLayout()，附加子層，然後設定layoutSizingHorizontal/Vertical。在設定尺寸模式之前使用resize()。 - 繫結，不要直接繪製。 填充、筆畫和文字顏色透過...
[已截斷以供翻譯]