doc-coauthoring：按三階段一起寫結構化文件

適合誰

doc-coauthoring 面向要寫結構化文本的人：文件、提案、技術規格、決策備忘，或同類內容。它不是自動交稿工具，而是主動帶著你走完三個階段：Context Gathering（收集上下文）、Refinement & Structure（打磨與結構）、Reader Testing（讀者測試）。

觸發條件寫得很直接：當你提到寫文件、做提案、起草規格或類似任務時使用。若你只是想隨便聊兩句、不接受分階段引導，說明允許你拒絕這套結構、改走自由發揮；但一旦接受，就應按階段推進，而不是跳到成稿。

它不適當作安裝程式。說明沒有給出任何安裝命令，也沒有寫把它放到某個目錄就算可用。若目前助手還不能按這套三階段工作，現有說明到此為止，不要從頁面地址反推安裝路徑。它也不適合在沒有讀者測試的情況下，把第一稿直接發給別人。

3 分鐘完成第一次嘗試

官方第一次路徑是開始共寫，而不是安裝。說明頁是

https://raw.githubusercontent.com/anthropics/skills/main/skills/doc-coauthoring/SKILL.md

請只按這一頁的階段做。不要編寫未出現的安裝句。

前置條件：目前助手已經能按 doc-coauthoring 的步驟引導，並且你手頭有一個低風險題目，例如一頁對內的決策備忘草稿。沒有安裝命令，因此「位置」就是這次對話，而不是某個推測出來的技能目錄。

低風險第一次任務：明確說出「我要寫一份決策備忘」，接受三階段引導，但只走完 Context Gathering。先回答助手關於讀者、目的和已知材料的問題，不要急著產生全文，更不要對外發送。若助手提到 Slack、Teams、Google Drive、SharePoint 或其它 MCP 可用來直接拉取上下文，先確認這些整合在你這邊是否真的可用；不可用就改用貼上或口述，不要假裝已經接通。

成功訊號是助手表明自己會按三個階段帶你走，並開始收集上下文，而不是直接吐出一篇完整文件。收集階段結束前，不要批准大段寫入檔案。說明沒有寫必須使用哪個編輯器，也沒有寫檔案格式。

使用案例

案例一：按三階段共寫一份規格或提案。當你提到寫文件、做提案或起草規格時啟動，助手充當主動嚮導：先收集上下文，再打磨結構和表述。適合你已經有素材、但需要有人按階段追問缺口的時候。說明沒有給出每階段的問題清單，因此只能做到「接受引導並逐段確認」。若助手跳過收集直接成稿，應要求回到 Context Gathering。說明頁仍是

https://raw.githubusercontent.com/anthropics/skills/main/skills/doc-coauthoring/SKILL.md

案例二：成稿前做讀者測試。第三階段是用一個沒有上下文的新 Claude 去讀這篇文件，抓住盲點，再讓別人讀。這適合你覺得自己寫得太順、擔心外人看不懂的時候。說明沒有寫如何一鍵開啟新會話，也沒有寫測試問題模板；因此只能做到「另開無上下文會話，把文件貼過去看對方能否複述要點」。測試未完成前，不要把文件當作已就緒。若整合可用，可用來拉上下文，但不能代替讀者測試。

使用界線

沒有安裝命令：說明只定義技能身分和三階段流程，不能把頁面路徑當成安裝程式。觸發界線：用於寫文件、提案、規格或同類結構化內容；其它寫作任務沒有被點名。流程界線：三個階段是收集上下文、打磨與結構、讀者測試；讀者測試必須用無上下文的新 Claude。整合界線：Slack、Teams、Google Drive、SharePoint 或其它 MCP 只有在「可用」時才能用來拉上下文，說明沒有保證這些整合一定存在，也沒有寫啟用步驟。拒絕引導時可以改自由發揮，但不要把自由發揮誤當成已經做完讀者測試。