| name | talk-structure |
| description | 整理、重組、檢視技術演講或簡報的內容結構與敘事。核心做法：用少數中性主軸詞當骨架、標題正面肯定、先講動機與變化、主軸逐一展開、用案例落地證明主軸（以問題開場當 hook）、並把『工作稿（含註記/討論/參考資料）』與『釋出稿（只有每頁標題/內容/講者註記）』分開維護。Use when organizing a talk/keynote/slide outline, restructuring a presentation's narrative, naming the 主軸/pillars of a talk, deciding section order, or splitting a messy working doc into a clean release deck. Triggers on 演講, 簡報, keynote, slide, 投影片, 講稿, 大綱, 主軸, 收斂, take away, 整理結構, 重整大綱, release. Do NOT use for line-level edit mechanics of marking changes (that's obsidian-revision-marks), for non-talk prose (articles/docs that have no slide/speaker-note shape), or for slide visual design / layout. |
演講內容結構化方法論
整理一場技術演講（keynote / 分享 / 簡報）的內容時, 處理的不是「逐字稿」, 而是敘事結構: 主軸是什麼、章節怎麼排、案例放哪、結論怎麼收。這個 skill 把一套可重複的結構化流程固定下來。
下面用一場真實演講當範例（91APP 的 AI Native keynote, 兩大主軸是 Core Cycle（流程） 與 Core Context（資訊））, 但方法本身適用於任何技術演講。
核心心法：主軸驅動 (pillar-driven)
一場好記的演講, 通常只有 2–3 個主軸, 整場所有內容都掛回這幾個主軸。聽眾記不住十個重點, 但記得住兩個主軸 + 一句 tagline。
整理流程的第一件事, 永遠是先問：這場的主軸是哪兩三個？叫什麼名字？ 其餘章節都是主軸的展開或佐證。
七個結構原則
1. 定調主軸名詞 — 中性、一致、jargon 留到對的地方
- 先挑定 2–3 個主軸, 給它們固定的名字, 全場一致使用, 不要中途換詞。
- 用中性、聽眾都懂的詞, 不要一開始就丟領域 jargon —— 因為一場對組織/團隊的演講, 內容不一定全落在某個技術領域, 有些屬於組織與流程管理。
- 但 jargon 不是不能用, 是留到對的地方（通常是 Take Away 或深入章節）才點明：「這個中性概念, 在 XX 領域就是 YY」。
- 範例：主軸定為 Core Cycle（流程）/ Core Context（資訊）（中性）; 到 Take Away 才點明「Core Cycle 在 AI coding 領域就是 Harness Engineering 的核心觀念」。
2. 標題正面化 — 用肯定句、答案前置
- 章節標題與投影片大字, 用正面肯定句, 明確說「要做什麼」, 避免否定句或純疑問句。
- 把答案前置到標題, 不要讓標題只是個懸念。
- 範例：「這是能 vibe coding 出來的系統嗎?」→「Vibe-codable 系統需要架構師的設計能力」。
3. 先講動機與變化 — 為什麼是現在
- 在丟方法論之前, 先用一段「為什麼 / 什麼變了」鋪陳動機, 讓主軸有出場的必要。
- 好用的手法：拿一個聽眾熟悉的既有框架（例：BizDevOps 循環、限制理論）, 演示舊的平衡被打破, 再把破口對接到你的主軸。
- 範例：AI 大幅加速 Dev → 限制理論下瓶頸轉移 → 瓶頸正好落在「架構師的邊界規劃（Core Cycle）」與「Core Context 管理品質」, 兩個主軸就此登場。
4. 主軸逐一展開 — 由小到大、善用對照表
- 每個主軸獨立成段, 常見的展開軸線是由小到大 / 由個人到團隊（例：工程師等級 → 架構師等級）。
- 對照表（左欄小尺度、右欄大尺度）是濃縮「同一套方法在不同尺度怎麼變」的利器。
5. 案例落地 — 用問題開場, 再用主軸解題
- 抽象講完要有一個貫穿的案例把主軸落地、證明可行。
- 案例用問題當開場 hook：先把問題講清楚, 丟一個「你會怎麼做？需要多少人力？」給聽眾, 讓他們先在心裡估一遍, 再示範你怎麼用主軸解。問題與解法擺在一起, 對比最強。
- 案例段落的骨架：問題 → （可選）DEMO → 用主軸解（關鍵決策）→ 落地步驟 → 結果/證據。
- 結果要可量化、可驗證（例：看每個 commit 的總行數/變更行數趨勢, 證明複雜度線性而非指數成長）, 不要只有形容詞。
6. 收斂 + Take Away + tagline
- 結尾把主軸明確回收成核心結論, 一個主軸一段。
- 這裡是點明 jargon 對應的好位置（原則 1）。
- 最後給一句 tagline, 一句話總結全部主軸, 當聽眾帶走的記憶點。
- 範例：「Harness 是骨架, Core Context 是燃料, 架構師的判斷力決定整個團隊的天花板」。
7. 工作稿 vs 釋出稿 — 兩份分開維護
整理過程會累積大量只對作者有用的東西：修訂註記、footnote 討論、參考資料連結、思考用的 ==think== 旁註。這些該留在工作稿, 不該污染給別人看的版本。
- 工作稿（
{talk}-draft.md）：保留所有註記、討論、參考資料、修訂標記, 是你迭代的地方。
- 釋出稿（
{talk}-release.md）：乾淨, 只有每頁簡報的「標題 / 內容 / 講者註記」, 移除一切 meta（footnote 註記、討論旁註、參考資料附錄）。
- 兩份內容結構一致, 釋出稿是工作稿「定稿後抽乾淨」的投影。
- 分工（持續修訂的基礎原則）：使用者只維護工作稿（draft）; 釋出稿（release）完全由 assistant 控制與定稿。循環是 —— 使用者在 draft 補內容 → assistant review、做結構決定（章節分階、取捨、收斂）、再抽乾淨成 release。使用者不直接編輯 release; 要改內容請回 draft, 由 assistant 重新定稿。
釋出稿格式
每一頁簡報固定三段：
## N. 章節標題 ← 第一階（section）
**內容**
- 投影片上會出現的重點（精簡, 大字, 條列）
**講者註記**
- 你會口頭補充、但不放上投影片的話（1–3 行）
### N.M 子投影片標題 ← 第二階（章節下的子頁）
**內容**
- ...
**講者註記**
- ...
要點：
- 內容 = 投影片上的字, 精簡到只剩骨; 講者註記 = 口語展開、例子、轉場、要強調的一句話。
- 工作稿裡同一個 bullet 常常混了「要顯示的」和「要講的」—— 釋出時把它拆開。
- 標題沿用正面化原則（原則 2）。
- 標題分兩階：第一階
## N. 是章節（section）, 第二階 ### N.M 是該章節下的子投影片。大章節（如 Case Study）就拆成多個子頁（問題 / 關鍵決策 / 步驟 / 結果 → 4.1 / 4.2 / 4.3…）。哪幾頁當第一階由 assistant 依敘事節奏決定。
圖表宣告（@figure）
釋出稿裡「圖該擺哪、從哪來」也要交代清楚, 讓下游一次生成簡報時能直接處理。在該頁「內容」中、圖要出現的位置, 放一行 @figure: 指令（宣告位置與來源, 不涉視覺排版）：
@figure: placeholder | <說明> | size=<尺寸> | source=<出處>
@figure: image <檔案路徑> | <說明> | size=<尺寸> | source=<出處>
@figure: code | <要畫什麼的描述> | size=<尺寸>
placeholder —— 圖還沒做好、之後再補; 下游產生可一鍵替換的佔位框。image <path> —— 圖已存在（向量優先給 SVG, 點陣給 2× PNG）; 路徑可絕對 / ~ / vault 相對。code —— 概念示意圖（黑箱 / 流程 / 拓樸）交給下游用向量直接畫。size：full（整頁主圖）/ half-left / half-right（圖文分欄）/ small（行內）/ 自填 1280x720。- 選用：
caption= 圖說、source= 出處（放成角落引用）。
要點：@figure: 宣告的是敘事位置與來源, 視覺（配色 / 線條 / 框）交給簡報層。一頁就是一張大圖時, 該頁「內容」只留這一行也行。
工作流程
- 先讀全文, 抓現況 —— 目前的主軸是什麼？章節順序？哪裡是動機、哪裡是案例、哪裡是結論？
- 定調主軸（原則 1）—— 跟使用者確認 2–3 個主軸的名字, 中性詞優先; 之後全程一致。
- 重排骨架（原則 3–6）—— 動機前置 → 主軸展開 → 案例落地 → 收斂。把每個章節對回它服務哪個主軸。
- 改工作稿 —— 在既有檔案上重排; 結構性變動用修訂標記（見下「與其他 skill 的關係」）讓使用者 review。
- 抽釋出稿 —— 結構定了之後, 另存
{talk}-release.md, 抽乾淨成「標題/內容/講者註記」, 並把每頁要用的圖用 @figure: 標好（見「圖表宣告」）。
- 收尾報告 —— 摘要：主軸是什麼、章節怎麼動、釋出稿在哪、還有哪些待確認（例：tagline 用詞、標題暫擬）。
整理大綱屬於需要對齊的工作 —— 結構性的重排先提案讓使用者確認, 不要默默大改。
與其他 skill 的關係
- 同屬
publish-review plugin（對外發表內容的 review 家族）：本 skill 負責演講/簡報格式; 規劃中的姊妹 skill 會涵蓋長文部落格（~100k 字）與短文社群貼文（~1k 字）。三者共用「先在 Obsidian 打草稿 → skill review → 抽乾淨釋出稿」的流程, 但各格式有自己的長度與形態紀律（演講重講者註記與口語節奏、長文重論證鋪陳、短文重「一句話打中」）。
- 搭配
obsidian-review:obsidian-revision-marks：那個 skill 處理「怎麼標記每一處變動」的語法機制（%%...%% 或 footnote）; 本 skill 處理「整場結構怎麼排」的策略層。重排工作稿時, 結構性變動（移動段落、改標題、新增框架）用 %%[移動/改/新增] 理由%% 標記, 讓使用者對照後再接受。
- 搭配
obsidian:obsidian-markdown：處理 wikilinks / callouts / 嵌入圖等 Obsidian 語法。
- 下游 open-slide
create-slide：以 @figure: 宣告的圖, 由它一次生成簡報時轉成佔位框 / <img> / 向量圖。本 skill 只宣告位置與來源, 視覺與替換由 open-slide 端處理。
何時不適用
- 逐字稿潤飾 / 純文章 —— 沒有「投影片 + 講者註記」的形態時, 用一般校稿流程即可。
- 投影片視覺設計 / 排版 —— 本 skill 只管內容結構與敘事, 不管視覺。
- 只是標記變動的語法問題 —— 那是
obsidian-revision-marks 的範圍。
- 使用者只要單點修改某一頁 —— 不需要動到整場結構時, 直接改即可。
