Communitygithub.com

r3xsean/設計流程

用於設計、重新設計或打磨產品UI時;用於對螢幕截圖進行設計評審時;或用於記錄使用者對設計的反應時。

設計流程 是什麼?

這個技能提供一個結構化的設計流程,幫助開發者和AI代理在產品UI設計過程中做出決策和記錄。它區分了使用者(決定方向與品味)和模型(執行任務)的角色,並強調使用者記錄的決定優先於AI的偏好。支援從新UI的引導(Bootstrap)、探索(Explore)、精煉(Refine)、評審(Council)到發布(Ship)的完整流程,也適用於現有UI的快速迭代。主要平台包括Claude Code、Cursor和Codex等AI編碼代理,透過明確的文件結構(如`docs/design/`下的`product-brief.md`、`DESIGN.md`、`harness.md`和`run.md`)來追蹤設計決策、使用者反應和評審結果。技能也內建使用者反應記錄機制,能將使用者的喜好、不喜歡或缺陷報告轉化為可追蹤的決定,並支援跨供應商的評審委員制度,確保設計方向的多樣性和客觀性。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/r3xsean/r3xstack/tree/HEAD/skills/design-process

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

設計流程 是做什麼的?

使用者決定方向與品味。模型評判執行:任務是否可行、數字是否正確、是否有任何東西破壞、隱藏或誤導。分數、評審團或模型共識永遠不會在方向之間做選擇、合併它們,或推翻已記錄的決定。

如果專案有自己的設計技能,請遵循它;它可能會將你送回此處以進行某個階段。

專案的檔案

除非專案的 AGENTS.md 為這些檔案指定了其他位置,否則它們位於 docs/design/:

  • product-brief.md:產品事實。誰使用它、每個介面必須讓他們做什麼(其主導問題和模式:操作、閱讀或說服)、資料與狀態、文案與信任邊界。如果專案已有 PRODUCT.md,則簡報連結到它而不是重複。
  • DESIGN.md:使用者的決定、例外情況、已核准的參考畫面以及反應記錄。已記錄的決定優先於你的偏好。若無記錄,則外觀是開放的;當前的 UI 是證據,不是決定。
  • harness.md:畫面與原型如何運作及被捕捉:指令、場景、視口、競爭對手應用程式、捕捉位置。
  • runs/<YYYY-MM-DD-名稱>/run.md:一次執行的問題、哪些是固定的與開放的、已知限制、評審委員與目標、立場關鍵字、結果。

所有四個的模板都在 templates/ 中。如果前三個檔案中缺少任何一個,請先引導。每次執行,包括跳過引導的執行,都會建立自己的 run.md。捕捉結果、清單、發現記錄與變體表格會放在 harness.md 命名的 gitignored 資料夾中。評審包則放在儲存庫外部,即工作階段的暫存區或暫存資料夾中。

專案自身的規則優先於此技能:其 AGENTS.md 中關於依賴項、開發伺服器以及要提交的內容。當執行需要某些這些規則禁止或保留供討論的內容時,請在執行前詢問使用者。

流程

  • 新 UI: 引導 → 探索 → 使用者選擇 → 精煉 → 評審 → 核准參考畫面 → 保留 → 透過專案的發布路徑發布。
  • 現有 UI: 引導 → 評審 → 核准 → 發布。當使用者希望先看到可見的變更時,先在評審前精煉。

從請求命名的階段進入;狹隘的調整從精煉階段進入。

階段優先閱讀
引導references/bootstrap.md,然後針對執行所需的每項能力閱讀 references/harness-contract.md
探索references/explore.md
精煉references/refine.md,以及在第一次 UI 編輯前閱讀 references/craft.md
評審references/council.md
使用其他設計技能references/integrations.md,在呼叫它之前閱讀

評審委員。 當執行將進入評審階段時,請在開始時詢問使用者誰是委員(每位委員的模型與推理努力),除非他們已經指定。建議來自不同供應商的委員。在 run.md 中記錄委員,並在整個執行過程中嚴格使用這些委員。如果某位委員無法使用,請告知;切勿替換。

核准參考畫面。 只有使用者的話語才能核准一個畫面;分數永遠不能代替。將其捕捉結果複製到 docs/design/references/,並在 DESIGN.md 的「參考畫面」下列出它們,說明每個畫面是哪個部分的參考。

保留。 在第一個核准的參考畫面之後,一個全新的代理根據此技能、專案檔案以及 harness 設計一個尚未被設計過的介面,並列出它必須猜測的每個點。向使用者展示結果。修正每個猜測,將其記錄在應該回答該猜測的檔案中,或將其記錄在 run.md 中作為開放項目。當使用者已做出反應且每個猜測都已修正或記錄時,即完成。

記錄反應

每當使用者對一個設計做出反應時,在任何階段:

  1. 每次反應在 DESIGN.md 的反應記錄中新增一行:日期(UTC)、介面與視口、哪個設計與捕捉執行、使用者的話語(精確引用)、類型、範圍、狀態為 observed。
    • 類型: like(保留它)、dislike(更改它)或 defect(任務失敗或有東西損壞;也將其新增到發現記錄中)。一個反應可以喜歡一部分而討厭另一部分;請命名每個部分。尚未建置的功能不是反應:在 run.md 中將其列在已知限制下。
    • 範圍 是使用者聲明的範圍:這個元素、這個介面類型或全站。如果他們未聲明,則範圍是該元素。切勿自己擴大範圍。
    • 你回應時更改的內容應放在發現記錄中,而不是這一行。
  2. 當使用者普遍聲明時,將一行提升為「決定」。當相同的反應在第二個介面上再次出現時,詢問它是否普遍適用,並且僅在得到肯定答覆時提升。將該行標記為 promoted 並附上連結。
  3. 當一個反應與一個決定矛盾時,詢問哪個勝出,然後編輯或刪除舊決定,並將失敗的行標記為 superseded。

當每個反應都有一行且每次提升都引用使用者的普遍聲明或他們的肯定答覆時,即完成。

隱私

捕捉結果應使用測試數據、種子數據或演示帳戶,切勿使用使用者自己的帳戶或真實人員的記錄。任何顯示個人數據或成人內容的內容都不得放入評審包、參考捕捉結果或提交內容中。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相關技能