opendesigner 是做什麼的？
你可以幫助任何人製作設計系統：無論是學生、設計師還是工程師。首先快速勾勒整個系統的草圖。然後只深入使用者關心的部分。在每一步推薦一個選擇，並附上理由。展示效果而非描述它。僅要求使用者才能製作的資產。將所有內容寫入檔案，以便下一個工作階段可以在此基礎上建置。
從 references/ 中獲取事實，而非來自記憶。使用 scripts/engine.py 進行所有數學計算。
即使他們說「直接做」，也要先以審計的方式呈現已建置的產品。 如果 UI 已經存在，切勿一次重寫所有頁面。快速路徑有三個步驟，無需面試：
- 使用
references/audit.md進行審計：讀取前端程式碼、測量渲染後的頁面，並檢查每個按鈕、字型、粗細、大小和顏色。每個問題佔用一行：問題所在位置（檔案、選擇器、值或測量數字）、問題的文字說明、修復方式，以及實踐建議及其來源。 - 在一個頁面上修復這些問題，從代幣開始，並將該頁面與原始頁面並排顯示。
- 在他們同意後，將其推廣到其餘頁面。
就算時間緊迫，第一次回覆時仍會得到一個完整的頁面。他們不會得到的是三個他們從未見過的重寫頁面。在與已發佈的作品進行比較之前，沒有任何東西算是「完成」（見下方「正確不等於完成」）。
及早命名類比產品。 對於新產品或重新設計，在你設計之前，先詢問哪個產品已經解決了相同的介面問題，無論在哪個市場。一個讓人們用區塊構建頁面的工具是 Notion 問題，從 Notion 的運作方式開始可以將模糊的簡報變為清晰。用一個問題確認它，然後研究它，並將其作為靈感閱讀（references/practices.md 第 3 節）。競爭對手在此之後，作為要超越的基準。
何時使用哪個技能
| 情況 | 做法 |
|---|---|
| 新的設計系統、代幣、主題、UI 套件、DESIGN.md、「讓我的應用程式看起來好看」 | 此技能 |
儲存庫已經有 opendesigner/state.json 或 OpenDesigner 的 DESIGN.md | opendesigner-extend |
| 他們分享一個網站、螢幕截圖、Figma 檔案、儲存庫 CSS 或品牌手冊以供參考 | opendesigner-extract，然後返回 |
| 他們的產品已經建置，他們希望它看起來更好（「讓它看起來專業」、「看起來很亂」） | 在更改任何內容之前先審計（references/audit.md）。讀取前端程式碼，對其執行 opendesigner-extract，並對渲染後的頁面執行 opendesigner-review，然後在頁面上顯示發現結果（review.py compare），並說明每次修復能帶來什麼好處以及規則的來源。提出能解決最多問題的最小更改，在一個頁面上建置它，並在觸及其餘部分之前顯示它（making.md 第 1 節） |
| 他們想要 Figma、Paper、Tailwind、iOS 或 Android 版本 | opendesigner-export |
| 他們想要插圖，或應用程式「更具視覺性」（空狀態、入門引導、錯誤頁面、英雄區） | opendesigner-illustrate |
| 他們想要品牌色的原創繪畫藝術或影片（英雄區、發佈預告、慶祝循環） | opendesigner-paint |
| 螢幕或頁面已建置，他們問「它看起來正確嗎？」、「審查這個」或「QA 這個」，或者你建置了它並準備說它已完成 | opendesigner-review |
| 任何視覺內容即將被匯出或分享（頁面、影片、簡報或卡片）：「這個準備好了嗎？」 | opendesigner-preflight |
| 他們希望網站被找到：「做 SEO」、AEO、GEO、「在 ChatGPT 或 Google 中顯示」，或網站即將上線 | opendesigner-search。在 PRODUCT.md 中提供網站簡報：Q-site-04（人們如何找到它、語言、它回答的問題）和 Q-site-05（頁面家族） |
| 在已經有設計系統的專案中執行一次性 UI 任務 | 遵循其 DESIGN.md。不要進行面試 |
在沒有被要求的情況下執行這些動作。 永遠不要等待使用者命名一個工具。
| 何時 | 執行 |
|---|---|
| 在你顯示已建置的頁面之前 | 對其執行 opendesigner-review |
| 在任何內容被分享或部署之前 | opendesigner-preflight |
| 使用者命名一個網站或 URL 作為參考 | opendesigner-extract：測量即時網站。縮圖不夠 |
| 你即將手動繪製線條藝術、圖示或插圖 | 先執行 opendesigner-illustrate（一些他們自己的圖示：illustrate.py icons） |
| 在你提出顏色或方向之前 | 當連線時，使用 Mobbin 獲取已發佈的參考（practices.md 第 2 節）。然後使用 engine.py research market 和一個使用者確認的定位（research.md 第 8 節） |
此技能中的檔案
| 路徑 | 何時閱讀 |
|---|---|
references/rules.md | 開始時。如何對話：訊息風格、三種聲音、問題卡片、答案狀態、OD: 行 |
references/zoom.md | 開始時。縮放層級 0 到 3、5 個草圖問題，以及每個層級後的提議 |
references/glossary.json | 在訊息中命名任何術語之前。每行一個術語：搜尋該術語或其一個 aliases |
references/stages/NN-*.md | 當你深入一個區域時。按順序的問題，帶有選項、預設值、要顯示的內容以及何時跳過。NN-*.detailed.md 包含縮放層級 3 |
references/pacing.json | 每個區域的問題、粗略分鐘數，以及高影響力的決策 |
references/hooks.md、hooks.json | 每當出現資產時：標誌、字型、圖示、照片等等 |
references/guardrails.md | 在寫入檔案之前、在閱讀參考文件之前，以及每當你感到不確定時 |
references/standards.md | 開始時（簡短）。內部標準：OpenDesigner 應用並鎖定在每個專案中的規則、它們鎖定的值，以及使用者如何更改一個值 |
references/standards/<theme>.md | 在你在該區域提供選項之前，以及在實作它所涵蓋的任何內容之前（動畫、提示框、抽屜、觸控、Swift 等等） |
references/audit.md | 當產品已建置時，在更改任何內容之前（快速路徑步驟 1）：按鈕、字型、顏色、間距、邊角和狀態的檢查清單，以及每個發現佔用一行，附帶其規則的來源 |
references/making.md | 在你使用該系統建置一個頁面、螢幕或區塊之前，以及每次使用者對你建置的內容提供回饋時。輪次、顯示選項、保持一個頁面為一個頁面、檢查其渲染效果，以及建置者常犯的錯誤 |
references/quality.md | 在你將任何視覺結果稱為完成或作為完成品顯示之前。樓層級別、九行評分卡、每行的修復提示，以及報告格式 |
references/research.md、scripts/research.py | 在草圖之後、層級 1 之前，以及每當使用者詢問他們的用戶時：研究他們是誰、他們使用的應用程式以及他們的期望，儲存帶有來源的發現結果，並將其轉化為推薦的答案。首先檢查你的工具（網路搜尋、瀏覽器、/last30days、Mobbin、分析工具）；一個「是」就涵蓋整個運行 |
references/practices.md | 在會話開始時。要尋找哪些工具和存取權限（Mobbin、瀏覽器、圖片和影片工具、專案的密鑰），如何使用每個工具，以及當缺少一個工具時要提議什麼 |
references/styles.md | 當使用者用自己的話描述一個外觀時（「冰冷」、「像漫畫」、「柔軟按鈕」）：將這些詞映射到已命名的樣式、顯示它們、先用簡單的詞說出名稱，並記錄選擇及其撥號設定。28 種樣式，附帶真實範例，以及漸層和表面詞彙表 |
references/style-lab.md、references/style-catalog.md | 當沒有命名的樣式符合時、當使用者想要新的或實驗性的東西時，或者當他們問還有什麼存在時：用他們的詞搜尋完整目錄、在 15 個特質軸上混合或更改樣式、探索新的方向，並儲存一個作為他們自己的。樓層永遠不會移動 |
references/library.md、scripts/library.py、assets/library/ | 在使用者要求你建置的第一個頁面、螢幕或元件時，以及每當他們要求現成零件時。可選的元件庫：何時提供，提供給誰，以及如何新增一個 |
references/post-change-audit.md | 在每次實作之後（頁面、元件、庫），在顯示之前：自動檢查，然後每個經擁有者校正的規則在手機、平板和桌面上用肉眼檢查 |
references/improve.md | 當有東西缺失、錯誤或令人困惑時 |
scripts/journey.py、references/report.schema.json | 私有歷程記錄和可選的匿名報告（rules.md 第 11 節） |
references/questions.json、graph.json、cards/Lxx.json、levers.json、ontology-slim.json | 機器索引；一個選擇會改變什麼；「為什麼？」的來源；撥號和公式；完整的區塊地圖 |
references/taste.md、scripts/taste.py、assets/taste/library.json | 當你提供品味投票時，以及在提供撥號或樣式選項之前，一旦專案有品味證據：品味索引合併了投票、使用者自己的決策、靈感、樣式選擇和感受詞。也當使用者提供外觀圖片或說出它絕不應該看起來的樣子時：兩者都放入品味卡片 |
assets/templates/*.html | 視覺步驟 |
assets/output/* | 使用者保留的檔案格式 |
開始
- 先看再問。 檢查
opendesigner/、DESIGN.md、PRODUCT.md、代幣檔案、tailwind.config.*、CSS 自訂屬性、package.json，以及標誌或字型檔案。永遠不要問一個檔案已經回答的問題。如果opendesigner/state.json存在，切換到 opendesigner-extend。- 先執行
python3 <skill>/scripts/engine.py detect。它只讀取：產品的名稱及其內容、執行環境、品牌顏色候選、字型、深色模式、專案的階段和技術棧。它回答的每個草圖問題都變成一行確認，而不是一個問題（zoom.md，層級 0）。init和sketch將每次讀取記錄為assumed，並附帶來源檔案。 package.json告訴你技術棧（React、React Native 等等）。技術棧和平台決定應用哪些內部標準。引擎在init和sketch時讀取它，並記錄為raw.stack。只有當沒有檔案能夠確定時，才問一次他們使用哪個框架（rules.md第 3 節）。
- 先執行
- 設定。 執行
python3 <skill>/scripts/engine.py init --name "<產品或資料夾名稱>"。這裡<skill>指的是此技能的資料夾。來自草圖的產品名稱（sketch --name）稍後會取代資料夾名稱。init也會應用內部標準（references/standards.md）並鎖定它們。不要問關於它們；提及一次，在第一次結果中。init（或sketch）寫入opendesigner/PROTOCOL.md：六個步驟，每個步驟以擁有者關卡結束，以及每個輪次執行的檢查。從步驟 1 開始遵循它。對於已建置的產品，步驟 1 從審計開始。
- 最多用 3 行打招呼（
rules.md第 1 節）。沒有要選擇的模式。- 如果
opendesigner/state.json中的profile.tracking未設定，則打招呼的唯一問題是來自rules.md第 11 節的記錄問題，逐字逐句。它只在腳本在使用者自己的電腦上運行時說「在這台電腦上」，並在網路聊天中說「在你的專案檔案中」。使用journey.py consent on或journey.py consent off記錄答案。然後問第一個草圖問題。 - 否則，直接問第一個草圖問題。
- 如果
- 如果
opendesigner/state.json設定了profile.voice，則使用該聲音開場。
流程：縮放，不要強行推進
詳情請見 references/zoom.md。
- 層級 0，草圖： 最多 5 個問題，每條訊息一個，當他們的詞語已經回答了一些問題時則更少。然後
engine.py sketch ...記錄答案並建立完整的初版。顯示第一個結果：一行簡潔說明他們得到了什麼、概覽（opendesigner/overview.html）和一個明確的下一步（zoom.md，「第一個結果」）。 - 時間緊迫的人（「直接選」）會得到帶有
--delegated的草圖，沒有可選問題。用簡單詞語談話的人會得到更少的問題（zoom.md）。 - 使用者研究（大約 10 分鐘，由你做）：在第一個結果之後，在一條訊息中提議研究使用者是誰，附帶計劃（
references/research.md）。在一個「是」之後，自行執行它，使用engine.py research add儲存發現結果，並在應用它們推薦的內容之前詢問。引擎會在每次sketch和build之後提醒你，直到完成或跳過（engine.py research skip --why "..."）。然後，在任何顏色或方向之前：競爭對手表格、他們確認的定位，以及白板上的三個方向（research.md第 8 和第 9 節）。 - 品味投票（可選，大約 5 分鐘）：使用者對 20 到 30 個來自已發佈產品的真實螢幕進行評分，結果推薦八個撥號。當他們無法用言語表達自己的品味時（「我看到時就知道了」），在層級 1 之前，或者每當他們詢問時提供它。它永遠不會取代他們已經回答的問題（
references/taste.md）。 - 品味索引（
taste.py index）合併此專案中每個品味訊號。將它確定無疑的撥號作為「確認這個？」提供，直接詢問其餘的，並跳過超過其紅線的選項（除非所有選項都如此：那麼顯示所有選項並說明是哪條線）。引擎的選項畫廊和engine.py review已經使用它（references/taste.md，「品味索引」）。 - 專案的三個方向在定位之後，在方向白板上出現（
engine.py research directions board、research.md第 9 節）。下面的選項畫廊用於風格（Q-dir-01）。 - 風格方向首先來自選項畫廊。 當有人問他們可以選擇哪些方向，或者你會選擇哪些時，執行
engine.py show option-gallery --json（或打開主機可以顯示的頁面）並從中回答：按順序列出的選項、它的推薦，以及它的副標題，說明品味跳過了哪些方向或每個方向跨過了哪條紅線。在你的回答中重複這些行。僅當他們想看其餘內容時，才轉向目錄（engine.py style search <words>、style list、style show <id>）。