open-slide 的工作流有一個容易被誤解的地方：/create-slide 不是「幫你想簡報」，它是把已經定案的骨架轉成一致的版面。agent 在版面一致性、型級遵守、資產處理上比人快且穩定；在決定 big idea、挑選最強反對意見、判斷哪個案例會打動這群人上，它幫不上忙。把這條界線畫清楚，這套工具鏈才有價值。
完整迴圈
① 人：寫 big-idea + outline（純文字，見 01）
② agent：/create-slide → 產出 slides/<id>/index.tsx
③ 人：dev server 裡看，用 inspector 直接改小東西 / 留 comment
④ agent：/apply-comments → 把 comment 變成程式碼修改
⑤ 人：git diff → review 結構與論證
⑥ 排練 → 改 notes → 回到 ③
⑦ build → 上台第 ① 步不能跳。跳過去直接叫 agent「幫我做一份關於 X 的簡報」，得到的會是一份結構正確但沒有主張的東西——它會有議程頁、三個並列的重點、一頁總結，也就是本專欄第一篇說的「主題而非主張」。
/create-slide：四個問題與一次規劃
這個 skill 是所有新 deck 的入口。流程固定四步：
- theme —
themes/裡有 theme 就先問要不要用。選了 theme 就等於定案視覺方向。 - scoping — 問四個問題：美學方向（已選 theme 則跳過）、頁數、文字密度、要動態還是靜態。
- id 與結構 — 決定 kebab-case 的 id，規劃頁面清單。
- 逐頁撰寫 — 寫出
slides/<id>/index.tsx，「怎麼寫」的部分交給/slide-authoring這份技術規格（型級、間距、色票、每頁垂直空間預算）。
prompt 的品質決定產出的品質。官方示範的顆粒度是 /create-slide for "Q2 launch — 3 chapters, mixed text density, subtle motion, dark aesthetic"。實務上把第 ① 步的 outline 直接餵進去會好得多：
/create-slide for「架構決策簡報，15 分鐘，深色極簡，動態克制，12 頁。
主張：我們該停在混合架構，不該繼續拆下去——邊際維運成本已超過解耦收益。
結構：
1 現況（一句話：目前 6 個服務，3 個共用同一個 DB）
2 裂縫（跨服務事務的 on-call 次數三個月成長 2.4 倍）
3 主張頁（只有那一句話）
4-5 支點一：解耦收益遞減，附三個月的變更前置時間資料
6-7 支點二：維運成本的組成拆解
8 最強反對意見：「不拆就無法獨立部署」→ 回應
9 S.T.A.R.：一張把兩條成本曲線交叉點畫出來的圖
10 行動：下週一架構會上凍結第二階段
11 收束句
12 附錄：完整成本表
每頁標題用完整句子寫結論，不要用名詞片語。」注意最後那一句——把本專欄的原則直接寫進 prompt，比事後一頁一頁改快得多。更持久的做法是把這些原則寫進 theme 的 markdown（theme 檔的 ## Voice 段落正是為此存在：「Tight, declarative, never coy. One concept per slide.」），/create-slide 每次都會讀。
theme：讓多份 deck 看起來像同一家
theme 是成對的兩個檔案，共用同一個檔名主幹：
themes/<id>.md— 給 agent 讀的配方：色票、字體、版面、固定元件、動態。front matter 有name/description/mode，內文自由格式。themes/<id>.demo.tsx— 一份可執行的迷你 slide，dev UI 的 Themes 面板會 import 它並渲染成預覽卡。它與一般 slide 模組同形，只是放在themes/下所以不會出現在 deck 清單。
官方提醒一個容易踩的維護問題：demo 裡的 Title / Footer / Eyebrow 等內嵌元件要與 markdown 裡的程式碼片段逐字保持同步——作者在 Themes 面板看到的，必須就是 /create-slide 會貼進真實 slide 的東西。兩者漂移的話，theme 就變成一個好看但不準的展示品。
已經有一份喜歡的 deck，可以用 /create-theme 把它的設計 token 抽成可重用的 theme。
inspector：兩種介入方式，不要混用
dev server 裡按 i（或工具列切換）打開 inspector overlay，點任何元素會出現屬性面板，可以改：文字內容、字體家族／字重／字級／字距、文字與背景顏色、圖片來源（可從該 deck 或全域 assets 換）。所有編輯先 buffer 在記憶體，按 SaveBar 的 Save 才一次寫回磁碟並觸發一次 HMR。
第二種介入是留 comment：inspector 會在該元素旁插入一個 @slide-comment 標記——一個普通的 JSX／JS 註解，執行期完全不影響輸出，內含你打的文字與指向該元素的指標。
判斷用哪一種的準則很簡單：
| 情況 | 用 |
|---|---|
| 改一個錯字、換一個顏色、調一級字 | inspector 直接改 |
| 「這頁太滿，拆成兩頁」 | comment，交給 agent |
| 「這張圖的高亮應該在第二段而不是第一段」 | comment |
| 「這個標題改寫成結論句」 | comment（因為要重寫，而不是換字） |
還有第三條路：inspector 的選取狀態對 agent 可見——點選一個元素後，選取資訊會寫進一個檔案，由 /current-slide skill 解析。這解決了對話中「把這個放大一點」的指涉模糊問題，agent 能確定「這個」是哪一個 JSX 節點。
/apply-comments：批次收斂
流程是：掃描 workspace 找出所有 @slide-comment → 讀取周圍程式碼與留言內容 → 修改檔案以滿足留言 → 移除標記。
› /apply-comments
✓ 3 markers · slides/q2-launch/index.tsx
✓ 1 marker · slides/intro/index.tsx實務上的用法是攢一批再跑——典型時機是一天工作結束前，或排練前。逐條留、逐條跑，會讓 agent 反覆讀同一個檔案，慢且容易互相覆寫。
留言模糊時，agent 會採取「最小的合理解釋」並在摘要中註明假設；完全無法解析的留言會原地保留並回報為 skipped，改寫措辭後重跑即可。這給了一個實用的寫留言原則：寫你要的結果，不要寫你要的手法。「這頁太擠，拆兩頁，第二頁只放成本曲線」比「把 margin 調小」好——前者 agent 有明確的成功條件，後者只是把你的猜測交出去。
review：把簡報當程式碼審查
git diff 對簡報的價值在於它讓論證的改動可見。三種值得建立的習慣：
- 結構性改動獨立成一個 commit。 只調整
export default [...]的順序，diff 就是三行，review 的人一眼看到「論證順序變了」。內容改動與結構改動混在一起，這個訊號就消失。 - 資料改動獨立成一個 commit。 數字更新時 diff 應該只有數字。這需要把數字集中在一個模組裡，而不是散落在 JSX 字面值中。
- review 的檢查清單針對內容而非程式碼：每頁標題是不是完整句子？有沒有哪一頁承載兩個重點？最強的反對意見在不在正文？
notes的索引有沒有跟頁面陣列對齊？
最後一條是實際會出事的地方：notes 是索引對齊的陣列，插入一頁而忘了插 undefined，後面所有備忘會錯位一格，而且在 dev server 上不會報錯，只有在 presenter view 上才會發現。把「notes 長度 === 頁數」當成 review 的固定檢查項。
跟一般工程專案的關係
這一套迴圈本質上就是 spec → generate → inspect → apply → review，與 工程化的 AI 編碼方法論 講的閉環同構：人負責意圖與驗收，agent 負責一致性與量。差別只在於這裡的「測試」是排練，「production」是那 15 分鐘的現場。