Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
文件共同撰寫工作流程
此技能提供結構化工作流程，引導使用者協作建立文件。扮演主動引導者，帶領使用者經歷三個階段：背景脈絡收集、優化與結構、以及讀者測試。
何時提供此工作流程
觸發條件：
- 使用者提到撰寫文件：「寫一份文件」、「草擬提案」、「建立規格」、「寫下來」
- 使用者提到特定文件類型：「PRD」、「設計文件」、「決策文件」、「RFC」
- 使用者似乎要開始一項重要的寫作任務
初始提議：
向使用者提供結構化工作流程以共同撰寫文件。說明三個階段：
- 背景脈絡收集：使用者提供所有相關背景，同時 Claude 提出釐清問題
- 優化與結構：透過腦力激盪和編輯，逐步建立每個章節
- 讀者測試：用全新的 Claude（無背景脈絡）測試文件，在其他人閱讀前找出盲點
說明這種方法有助於確保文件在其他人閱讀時（包括當他們貼到 Claude 時）能正常運作。詢問他們是否想嘗試此工作流程，或偏好自由發揮。
如果使用者拒絕，則自由發揮。如果接受，則進入階段 1。
階段 1：背景脈絡收集
**目標：**縮小使用者所知與 Claude 所知之間的差距，以便後續提供智慧引導。
初始問題
首先詢問使用者關於文件的後設背景：
- 這是什麼類型的文件？（例如：技術規格、決策文件、提案）
- 主要讀者是誰？
- 希望讀者閱讀後產生什麼影響？
- 是否有範本或特定格式要遵循？
- 還有其他限制或背景需要知道嗎？
告知他們可以用簡寫回答，或以最適合的方式傾倒資訊。
如果使用者提供範本或提到文件類型：
- 詢問他們是否有範本文件可以分享
- 如果他們提供共享文件的連結，使用適當的整合功能擷取
- 如果他們提供檔案，讀取該檔案
如果使用者提到編輯現有的共享文件：
- 使用適當的整合功能讀取當前狀態
- 檢查是否有缺少替代文字的圖片
- 如果圖片沒有替代文字，說明當其他人使用 Claude 理解文件時，Claude 無法看到這些圖片。詢問是否要產生替代文字。如果是，請他們將每張圖片貼到對話中，以便產生描述性替代文字。
資訊傾倒
一旦初始問題回答完畢，鼓勵使用者傾倒他們擁有的所有背景。請求提供以下資訊：
- 專案/問題的背景
- 相關團隊討論或共享文件
- 為何不使用其他解決方案
- 組織背景（團隊動態、過去事件、政治因素）
- 時間壓力或限制
- 技術架構或依賴關係
- 利害關係人的顧慮
建議他們不用擔心組織整理——只要全部說出來就好。提供多種提供背景的方式：
- 意識流式資訊傾倒
- 指向團隊頻道或討論串供讀取
- 連結到共享文件
如果有可用的整合功能（例如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 伺服器），提及這些可以用來直接拉取背景。
**如果在 Claude.ai 或 Claude 應用程式中未偵測到整合功能：**建議他們可以在 Claude 設定中啟用連接器，以便直接從訊息應用程式和文件儲存中拉取背景。
告知他們在完成初步傾倒後，會提出釐清問題。
在背景收集期間：
-
如果使用者提到團隊頻道或共享文件：
- 如果有可用的整合功能：告知他們現在將讀取內容，然後使用適當的整合功能
- 如果沒有可用的整合功能：說明無法存取。建議他們在 Claude 設定中啟用連接器，或直接貼上相關內容。
-
如果使用者提到未知的實體/專案：
- 詢問是否應該搜尋已連接的工具以了解更多
- 等待使用者確認後再搜尋
-
當使用者提供背景時，記錄學到的內容以及仍不清楚的部分
提出釐清問題：
當使用者表示已完成初步傾倒（或在提供大量背景後），提出釐清問題以確保理解：
根據背景中的缺口，產生 5-10 個編號問題。
告知他們可以用簡寫回答（例如「1：是，2：見 #channel，3：否因為向後相容」）、連結到更多文件、指向要讀取的頻道，或繼續傾倒資訊。以對他們最有效率的方式進行。
退出條件：
當問題顯示已充分理解——能夠詢問邊界情況和取捨，而無需解釋基礎知識時，表示已收集足夠背景。
過渡：
詢問他們在此階段是否還有更多背景要提供，或者是否該進入草擬文件階段。
如果使用者想補充更多，讓他們補充。準備好後，進入階段 2。
階段 2：優化與結構
**目標：**透過腦力激盪、篩選和迭代優化，逐步建立文件的每個章節。
給使用者的指示：
說明文件將逐章節建立。對於每個章節：
- 會提出釐清問題，詢問應包含哪些內容
- 會腦力激盪 5-20 個選項
- 使用者會指出要保留/移除/合併哪些內容
- 會草擬該章節
- 會透過精確編輯進行優化
從最不確定的章節開始（通常是核心決策/提案），然後處理其餘部分。
章節順序：
如果文件結構明確：
詢問他們想從哪個章節開始。
建議從最不確定的章節開始。對於決策文件，通常是核心提案。對於規格文件，通常是技術方法。摘要章節最好留到最後。
如果使用者不知道需要哪些章節：
根據文件類型和範本，建議 3-5 個適合該文件類型的章節。
詢問這個結構是否可行，或者他們是否想調整。
一旦結構確定：
建立初始文件結構，所有章節都使用佔位文字。
如果可以存取 artifacts：
使用 create_file 建立 artifact。這為 Claude 和使用者提供了可操作的框架。
告知他們將建立包含所有章節佔位文字的初始結構。
建立包含所有章節標題和簡短佔位文字（如「[待撰寫]」或「[內容在此]」）的 artifact。
提供 scaffold 連結，並表示是時候填入每個章節的內容了。
如果無法存取 artifacts：
在工作目錄中建立一個 Markdown 檔案。適當命名（例如 decision-doc.md、technical-spec.md）。
告知他們將建立包含所有章節佔位文字的初始結構。
建立包含所有章節標題和佔位文字的檔案。
確認檔案已建立，並表示是時候填入每個章節的內容了。
對於每個章節：
步驟 1：釐清問題
宣布將開始處理 [章節名稱] 章節。提出 5-10 個關於應包含內容的釐清問題：
根據背景和章節目的，產生 5-10 個具體問題。
告知他們可以用簡寫回答，或僅指出哪些內容重要。
步驟 2：腦力激盪
對於 [章節名稱] 章節，根據章節複雜度，腦力激盪 [5-20] 個可能包含的項目。尋找：
- 可能被遺忘的已分享背景
- 尚未提及的角度或考量
根據章節複雜度產生 5-20 個編號選項。最後，提供繼續腦力激盪更多選項的機會。
步驟 3：篩選
詢問哪些要點應保留、移除或合併。請求簡短理由，以幫助學習下一個章節的優先順序。
提供範例：
- 「保留 1,4,7,9」
- 「移除 3（與 1 重複）」
- 「移除 6（讀者已經知道）」
- 「合併 11 和 12」
如果使用者提供自由形式回饋（例如「看起來不錯」或「大部分喜歡但...」）而非編號選擇，則提取他們的偏好並繼續。解析他們想要保留/移除/更改的內容並套用。
步驟 4：缺口檢查
根據他們選擇的內容，詢問 [章節名稱] 章節是否遺漏了任何重要內容。
步驟 5：草擬
使用 str_replace 將此章節的佔位文字替換為實際草擬的內容。
宣布現在將根據他們選擇的內容草擬 [章節名稱] 章節。
如果使用 artifacts：
草擬後，提供 artifact 的連結。
請他們閱讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
如果使用檔案（無 artifacts）：
草擬後，確認完成。
告知他們 [章節名稱] 章節已草擬於 [filename] 中。請他們閱讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
給使用者的關鍵指示（在草擬第一個章節時包含）：
提供備註：請他們不要直接編輯文件，而是指出要更改的內容。這有助於學習他們的風格，以便後續章節。例如：「移除 X 項目符號——Y 已涵蓋」或「讓第三段更簡潔」。
步驟 6：迭代優化
當使用者提供回饋時：
- 使用
str_replace進行編輯（絕不重新列印整份文件） - **如果使用 artifacts：**每次編輯後提供 artifact 連結
- **如果使用檔案：**僅確認編輯完成
- 如果使用者直接編輯文件並要求讀取：在心裡記下他們所做的更改，並在後續章節中記住（這顯示了他們的偏好）
持續迭代直到使用者對該章節滿意。
品質檢查
在連續 3 次迭代沒有實質性更改後，詢問是否可以移除任何內容而不遺失重要資訊。
當章節完成時，確認 [章節名稱] 已完成。詢問是否準備好進入下一個章節。
對所有章節重複。
接近完成
當接近完成（80% 以上的章節完成）時，宣布將重新閱讀整份文件並檢查：
- 各章節之間的流暢度和一致性
- 冗餘或矛盾
- 任何感覺像是「廢話」或通用填充的內容
- 每個句子是否都有分量
閱讀整份文件並提供回饋。
當所有章節都草擬並優化完成：
宣布所有章節都已草擬。表示將再審查一次完整文件。
審查整體連貫性、流暢度、完整性。
提供任何最終建議。
詢問是否準備好進入讀者測試，或者是否想進一步優化。
階段 3：讀者測試
**目標：**用全新的 Claude（無背景脈絡洩漏）測試文件，以驗證其對讀者有效。
給使用者的指示：
說明現在將進行測試，以確認文件是否真的對讀者有效。這能找出盲點——作者覺得合理但可能讓其他人困惑的內容。
測試方法
如果可以存取子代理（例如在 Claude Code 中）：
直接進行測試，無需使用者參與。
步驟 1：預測讀者問題
宣布將預測讀者在嘗試發現此文件時可能提出的問題。
產生 5-10 個讀者會實際提出的問題。
步驟 2：使用子代理測試
宣布將用全新的 Claude 實例（無此對話的背景）測試這些問題。
對於每個問題，調用一個子代理，僅提供文件內容和該問題。
總結 Reader Claude 對每個問題回答正確/錯誤的部分。
步驟 3：執行額外檢查
宣布將執行額外檢查。
調用子代理檢查模糊性、錯誤假設、矛盾。
總結發現的任何問題。
步驟 4：報告與修正
如果發現問題：
報告 Reader Claude 在特定問題上遇到困難。
列出具體問題。
表示將修正這些缺口。
回到有問題章節的優化階段。
如果無法存取子代理（例如 claude.ai 網頁介面）：
使用者需要手動進行測試。
步驟 1：預測讀者問題
詢問人們在嘗試發現此文件時可能提出的問題。他們會在 Claude.ai 中輸入什麼？
產生 5-10 個讀者會實際提出的問題。
步驟 2：設定測試
提供測試指示：
- 開啟一個全新的 Claude 對話：https://claude.ai
- 貼上或分享文件內容（如果使用已啟用連接器的共享文件平台，提供連結）
- 向 Reader Claude 詢問產生的問題
對於每個問題，指示 Reader Claude 提供：
- 答案
- 是否有任何模糊或不清楚的地方
- 文件假設讀者已經知道哪些知識/背景
檢查 Reader Claude 是否給出正確答案或誤解任何內容。
步驟 3：額外檢查
也詢問 Reader Claude：
- 「這份文件中哪些內容可能對讀者模糊或不清楚？」
- 「這份文件假設讀者已經具備哪些知識或背景？」
- 「是否有任何內部矛盾或不一致？」
步驟 4：根據結果迭代
詢問 Reader Claude 回答錯誤或遇到困難的內容。表示將修正這些缺口。
回到任何有問題章節的優化階段。
退出條件（兩種方法皆適用）
當 Reader Claude consistently 正確回答問題，且不再出現新的缺口或模糊性時，文件就準備好了。
最終審查
當讀者測試通過時：
宣布文件已通過 Reader Claude 測試。在完成之前：
- 建議他們自己進行最終通讀——他們擁有這份文件並對其品質負責
- 建議再次檢查任何事實、連結或技術細節
- 請他們確認文件達到了他們想要的影響
詢問他們是否想要再審查一次，或者工作是否完成。
如果使用者想要最終審查，提供審查。否則：
宣布文件完成。提供一些最終提示：
- 考慮在附錄中連結此對話，以便讀者了解文件的開發過程
- 使用附錄提供深度，而不使主文件臃腫
- 根據真實讀者的回饋更新文件
有效引導的技巧
語氣：
- 直接且程序化
- 在影響使用者行為時簡短說明理由
- 不要試圖「推銷」這個方法——直接執行
處理偏離：
- 如果使用者想跳過某個階段：詢問他們是否想跳過並自由發揮
- 如果使用者感到沮喪：承認這比預期花費更長時間。建議加快速度的方法
- 始終讓使用者有權調整流程
背景管理：
- 在整個過程中，如果缺少關於某個提及事項的背景，主動提問
- 不要讓缺口累積——在出現時就處理
Artifact 管理：
- 使用
create_file草擬完整章節 - 使用
str_replace進行所有編輯 - 每次更改後提供 artifact 連結
- 絕不使用 artifacts 進行腦力激盪列表——那只是對話
品質重於速度：
- 不要急著完成階段
- 每次迭代都應帶來有意義的改進
- 目標是產出一份對讀者真正有效的文件
