美術
教材產製 HTML
避免做完才發現不是你要的。
開工前先定義讀者、主線、章節、圖解、手機驗收、禁止字眼。你核准設計後，再產生 HTML。
先看網路怎麼解釋
第一手來源
GitHub Superpowers 的定義
Superpowers 把 設計討論 放在基本工作流第一步。官方 儲存庫 說它會在寫 程式碼 前啟動，用問題釐清粗略想法、探索替代方案、分段展示設計，最後保存設計文件。
重點：它是整套 agentic engineering 工作流程 的入口，不是單獨的聊天技巧。
寫程式之前設計核准儲存設計文件
Skill.md 規則
Brainstorming Skill 的硬規則
Brainstorming Skill 本文要求：先理解專案上下文、一次問一個問題、提出 2-3 種方案與 取捨、分段讓使用者核准；未取得設計核准前，不寫 程式碼、不 建立骨架、不做任何實作。
重點：它把「先想清楚」變成可執行的流程閘門。
一次一題2–3 種做法尚未開始實作
O
OpenAI 技能 文件
技能是可重複工作流。
OpenAI 文件把 技能 定義成包裝 指引、素材、optional 腳本 的工作流格式。這表示 設計討論 這類流程適合被沉澱成 技能，而不是每次貼長 提示詞。
A
Addy Osmani 工作法
先有規格，再寫程式。
AI coding 工作流程 的常見建議是先用 AI brainstorm 出 detailed specification，再拆 step-by-step plan，最後才進 程式碼。這跟 設計討論 -> Writing Plans 的方向一致。
M
Matt Pocock 技能
先解決人機誤會。
Matt Pocock 的 技能 儲存庫 把「代理 沒做出我要的」歸因於 misalignment，解法是先讓 代理 深入提問。這可視為 設計討論 前半段的需求對齊能力。
心智模型：不是發想，是設計閘門
「想法」不能直接交給 代理 寫；要先變成「設計」。
對人類來說，很多背景知識在腦中；但 代理 看到的是目前 上下文。如果一開始只給一句模糊需求，它會自己補齊缺口。Brainstorming Skill 的價值，是讓 代理 先暴露假設、問清楚限制、提出路線選擇，等你核准後才往下做。
它最適合處理這種狀況：你大概知道要做什麼，但還沒決定邊界、架構、輸出形式、驗收標準，或不知道哪種做法風險最小。
Michael AI Agent Lab 版翻譯把 設計討論 當作「開工前設計審查」。它不是要求每個小任務寫長文件，而是要求每個任務至少有一個可核准的 簡短設計。
視覺模型
SOP：從想法到可執行計畫
1
探索上下文
先看現有文件、檔案、近期變更、專案慣例。若工作太大，先拆成子題。
2
一次一題
只問一個問題。優先問目的、限制、成功標準、不可做事項。
3
提出 2-3 方案
每個方案要有 取捨。代理 要給推薦方案與理由。
4
分段核准
架構、資料流、UI、錯誤處理、測試分段給你看，不一次塞滿。
5
寫設計文件
把核准內容寫成 規格，檢查 TODO、矛盾、模糊、範圍 過大。
6
轉實作計畫
你 審核 後，才進 Writing Plans、TDD、subagent 或 Codex 實作。
跟其他工作法怎麼分工
| 工作法 | 主要用途 | 輸入 | 輸出 | 何時用 |
|---|---|---|---|---|
| Grill Me | 需求訪談，把人腦裡的資訊問出來。 | 模糊想法、任務方向。 | 需求、限制、名詞、成功標準。 | 你還不知道要怎麼描述需求時。 |
| 腦力激盪技能 | 把需求變成設計，並拿到核准。 | 已釐清的需求或初步方向。 | 方案比較、推薦路線、設計文件。 | 要做功能、教學頁、代理 工作流程 前。 |
| PRD／規格 | 把設計固定成可追蹤的合約。 | 核准後的設計。 | 需求、資料流、邊界、測試、驗收。 | 多人協作或長期維護時。 |
| 撰寫計畫 | 把 規格 拆成小任務。 | 已 審核 的 規格。 | 檔案路徑、步驟、驗證命令。 | 準備讓 Codex 或 subagent 開工時。 |
| TDD／審查 | 確保實作可驗證。 | 實作任務。 | 測試結果、審核 findings、修正。 | 任何會改 程式碼 或流程的地方。 |
套用到 AI 代理 工作流
程式
Codex 改功能
避免 代理 自己選路線。
改 程式碼 前先讀 codebase，提出保守修補、局部重構、抽象化三種方案與風險。小任務也要有 簡短設計。
PM
PM 工作流程 報告
避免只有摘要，沒有決策。
先確認讀者、決策、風險、負責人、deadline、下一步，再做報告。這會讓輸出更像 PM brief，不是資料堆疊。
Wiki
Wiki Agent 研究
避免未驗證知識進正式庫。
研究前先定義來源標準、信心等級、時間範圍與 raw/inbox 路徑。正式知識要有來源，不要靠聊天印象。
要不要安裝 Superpowers？
建議：先吸收 設計討論 規則，不急著全裝進 Hermes 核心。Superpowers 是一整套 agentic engineering 工作流程。對 Hermes 來說，最有價值的是「先設計、再計畫、再執行」這個工作順序；外部整包 plugin 要等 隔離環境 測過、確認不會覆蓋本機規則後再考慮。
可以先做
- 把 上下文 -> Questions -> Options -> Design -> Approval -> Plan 寫進 Codex 技能 sync。
- 高風險任務要求完整 規格；小任務用 簡短設計。
- 讓教材產製 代理 每次製作教學 HTML 前先列設計 brief。
- 讓 Codex 改 程式碼 前固定提出 2-3 方案。
先不要做
- 不要把 raw chat、代元、cookie、客戶機密寫入 技能。
- 不要讓外部 工作流程 覆蓋 Hermes 現有安全規則。
- 不要每個小修改都要求長篇 設計文件。
- 不要把 設計討論 當作拖延實作的藉口。
可直接複製的提示詞
通用版
請先用 Brainstorming 流程，不要直接實作。 請先完成： 1. 探索目前上下文 2. 一次問我一個釐清問題 3. 提出 2-3 種方案與 trade-off 4. 推薦一個方案並說明理由 5. 分段給我確認設計 我核准前，不要寫 code、不要改檔案。
Michael 教學筆記 HTML 版
請先設計這份 Michael 教學筆記，不要直接產 HTML。 請提出： - 讀者與目的 - 核心主線 - 章節架構 - 需要圖解的地方 - 手機驗收標準 - 來源與信心等級 - 不能出現的字眼 我核准設計後，再做 HTML。
Codex 改功能版
請先探索 codebase，提出 2-3 種修改方案。 每個方案請列： - 會改哪些檔案 - 風險 - 測試方式 - rollback 方式 - 是否需要重構 等我選定方案後，再寫 implementation plan。
設計自檢版
請自我檢查這份設計： - 是否有 TODO 或 TBD - 是否有矛盾 - scope 是否太大 - 哪些需求可能被不同解讀 - 驗收方式是否明確 請先修正設計，再請我 review。