iamshadmirza/to-onepager

將對話轉換為一頁摘要：一個主張、有根據的證據、易於閱讀和遵循、以及已設定的發佈目的地。

輸入： 提供的逐字稿路徑/貼上內容；否則為當前對話。setup / reconfigure → 即使 config.md 已存在也執行設定。

配置： config.md 位於此 SKILL.md 旁（安裝目錄的本機）。格式：config.example.md。

頁面類型（有效類型）： research-finding | proposal。不明確時優先選擇 research-finding。如果兩者都符合，只問一次。在擬稿前宣布選擇。

步驟

0. 設定

如果 config.md 遺失或用戶要求重新配置：

1. 詢問目的地：local | google-docs | confluence（只能選一個）。
2. 收集該目的地所需的欄位（請參閱 config.example.md）。Confluence 需要 confluence_folder_url。
3. 在此技能目錄中寫入 config.md。
4. 告知用戶此設定將適用於所有未來執行；說 setup 以變更設定。

完成條件： 存在有效的 config.md，且包含已知的 destination。除非也請求了產生一頁摘要，否則僅設定模式的執行到此為止。

1. 挖掘

讀取完整輸入。僅供工作筆記使用（不向用戶顯示）：

• 會議意圖：經驗性主張 vs 決策賭注
• 整個會議服務於哪個問題或難題
• 已測試的假設（先列出修正/已改變的內容）
• 有根據的事實（有來源）vs 無來源的主張（中等信心）
• 方法、限制、未解決的問題、下一步行動（產品/研究決策，非本機操作手冊）

如果意圖傾向 research-finding，也需捕捉：

• 帶有計數的解釋機制（主導訊號、FP 模式、反事實）
• 用戶強調的發現（「把這個放在主要發現中」）
• 實驗？ 如果會議比較了 N 個條件下的相同衡量指標（帽蓋、模式、範圍、配置、A/B 組），請列出每個條件以及決定性的表格（記分卡、差距組成、相等性檢查）。標記 fill: experiment。

如果意圖傾向 proposal，也需捕捉：

• 問題 / 誰受到影響、推薦的賭注、為何現在、方法、替代方案（有來源時提供）、風險
• 會議中討論的近期下一步行動

完成條件： 已捕捉意圖訊號、修正、有來源的事實以及分支特定的筆記。尚不解釋。

2. 路由

從以下類別中精確選擇一種頁面類型。宣布：Page type: …。

頁面類型	使用時機	當以下情況優先選擇另一種
research-finding	證據回答了「什麼是真的？」	會議主要是賭注，幾乎沒有新證據
proposal	會議建構了一個賭注（問題、路徑、原因、方法）	會議是純粹的衡量，沒有建議的改變

保留驗證和架構供後續處理；如果會議僅包含這些形狀，請詢問哪種即時類型最接近，或停止。

完成條件： 已選擇並宣布一種頁面類型。

3. 提煉

載入所路由類型的範本（上下文指標 — 僅讀取該檔案）：

• research-finding → templates/research-finding.md
• proposal → templates/proposal.md

為便於閱讀填入該主幹：一個從頭開始閱讀的人應能在數秒內掌握主張，並跟隨每個章節的單一脈絡。

research-finding 填入路徑

• 預設： 假設 → 結果 → 主要發現（範本預設主幹）。
• 實驗（當挖掘步驟標記了 fill: experiment 時）：使用範本實驗主幹。宣布：Fill path: experiment。
  • 發現階梯： 堆疊的項目符號（每個條件一個結論）加上可選的底線；不要將 N 個條件塞入一個超長句子。
  • 條件前的背景（可選）： 在 Answer 之後，一個簡短的區塊，解釋比較的各方以及任何容易混淆的術語（例如類型與實例計數），以避免誤讀表格。僅在 Question 不夠用時使用。優先使用簡單的標題如 如何閱讀；不需要時省略。不要發明強制性的章節名稱。
  • 條件章節： 每個條件一個頂層章節；每個包含結論接著分析。以公平性或結果命名章節（例如「公平 A/B：已移除帽蓋」），而不僅僅是原始旋鈕（「MaxMessages = 100」）。將可分享的證據放入分析中（記分卡和/或相同結論 / 差距組成表格）。
  • 重複驗證： 嵌套在決定性/公平的條件下（例如多會話檢查）；不要只為了重複而添加頂層條件章節。
  • 不要將 N 個條件的實驗扁平化為假設 → 結果 → 主要發現。

可讀性（每個頁面）

• 以具體事物開頭： 標題和 Finding 以數字、結論或賭注開頭。上下文隨後；它不開啟頁面。對於實驗，Finding 可能以項目符號階梯承載賭注；如果 Finding 包含數字，標題可以命名比較。
• 範例後解釋： 在結果、主要發現、分析和方法中，先陳述衡量結果或選擇的路徑，然後必要時提供一行簡短的上下文。
• 每個章節一個職責： 每個標題只做一件事。如果一個章節在論證兩件事，請分割或刪減。
• Answer 讓從頭開始閱讀的人可以在不在乎頁面類型的情況下使用：Finding（TLDR）/ 信心 / 所以呢
• 標題是主張（當逐字稿有測量數字時包含該數字；實驗可以將數字放在 Finding 中）
• 建議：僅限會議中討論的行動。如果會議僅回答了一個問題（封閉式研究，無產品賭注），請寫無（或「研究完成；無後續動作」）— 不要發明下一步、文件待辦事項、審閱者作業或「~1 週」計劃。
• 頁首：擁有者、深入了解
• 包含審閱章節

擁有者：確認一個真人。對於 Confluence 目的地，發佈時使用 Atlassian 提及（publish.md）。否則使用顯示名稱。如果未知則詢問；只有暫緩時才使用 TBD。

完成條件： 已填入路由主幹（預設或實驗）；頁首元素完整；擁有者已確認或明確標示 TBD；標題和 Finding 以具體主張開頭。

4. 品質控管

檢查並編輯直到每一項檢查都通過。此步驟是品質的唯一真實來源（範本不會重述這些規則）。

每個頁面

• 每個事實性儲存格/項目符號都能追溯到逐字稿
• 沒有未經測量的量級
• 從頭開始閱讀者的 Answer 無需閱讀頁面類型即可理解；Finding 是 TLDR 並以具體主張開頭（實驗 Finding 可以是項目符號階梯）
• 標題以主張開頭（不是主題或軟性標題）；如果 Finding 承載賭注/數字，實驗可以在標題中命名比較
• 內文與路由的頁面類型相符（無混合主幹）
• 每個章節一個職責；沒有既解釋又建議的章節
• 頁首元素完整（擁有者、深入了解）
• 深入了解 / 建議保持無關本機操作手冊的雜亂
• 信心與證據相符；當有測量數字時，標題與數字相符（對於實驗階梯，則為 Finding 相符）
• 一頁預算： 約 600 字的散文；如果超過，刪減最不重要的想法（不要縮小字體或塞入附錄）。例外： 實驗的決定性表格（記分卡、差距組成、相等性檢查）不會為了達到預算而被刪減；改為縮短它們周圍的項目符號。
• Answer + 建議的樸實通過： 主動語態、簡短詞彙、刪除不必要的詞彙和術語
• 無模板橋接： 刪除諸如「在當今環境中」、「遊戲規則改變者」、「這就是為什麼這很重要」或僅為提高參與度而添加的結尾問題等短語
• 無軟性總結： 建議不重新表述 Finding
• 無發明的後續動作： 僅在逐字稿中討論過的情況下才包含下一步；否則建議為無 / 研究完成
• 每個章節都增加新內容； 刪除僅重述先前章節的填充內容