Menu
引導使用者完成結構化文件共同撰寫的工作流程。當使用者想撰寫文件、提案、技術規格書、決策文件或類似的結構化內容時使用。此工作流程幫助使用者有效傳遞上下文、透過迭代精煉內容，並驗證文件對讀者是否有效。當使用者提到撰寫文件、建立提案、草擬規格書或類似文件任務時觸發。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
使用 Claude API / Anthropic SDK 建構、除錯和最佳化應用程式。使用此技能建構的應用程式應包含提示快取 (prompt caching)。也處理在 Claude 模型版本之間遷移現有 Claude API 程式碼（4.5 → 4.6，4.6 → 4.7，替換已退役模型）。觸發時機：程式碼匯入 anthropic/@anthropic-ai/sdk；使用者要求使用 Claude API、Anthropic SDKs 或 Managed Agents (/v1/agents, /v1/sessions, /v1/environments)；使用者在檔案中新增/修改/調整 Claude 功能（快取、思考、壓縮、工具使用、批次、檔案、引用、記憶）或模型（Opus/Sonnet/Haiku）；關於 Anthropic SDK 專案中提示快取/快取命中率的問題。不觸發：檔案匯入 `openai`/其他提供者 SDK，檔案名稱類似 `*-openai.py`/`*-generic.py`，與提供者無關的程式碼，一般程式設計/機器學習。
當編寫呼叫 Gemini API 的程式碼時請使用此技能，用於文字生成、多輪對話、多模態理解、影像生成、串流回應、背景研究任務、函式呼叫、結構化輸出，或從舊的 generateContent API 遷移。此技能涵蓋 Interactions API，這是在 Python 與 TypeScript 中使用 Gemini 模型與代理的建議方式。
Tailwind CSS v4 原則。CSS 優先配置、容器查詢、現代模式、設計 token 架構。
處理使用 Gemini Live API 的即時、雙向串流應用程式時使用此技能。涵蓋基於 WebSocket 的音訊/視訊/文字串流、語音活動偵測 (VAD)、原生音訊功能、函式呼叫、會話管理、用戶端身分驗證的臨時權杖，以及所有 Live API 設定選項。涵蓋的 SDK - google-genai (Python)、@google/genai (JavaScript/TypeScript)。
Python 開發原則與決策。框架選擇、非同步模式、型別提示、專案結構。教你思考而非複製。
自動代理選擇與智慧任務路由。分析使用者請求並自動選擇最佳專家代理，無需使用者明確提及。
| name | doc-coauthoring |
| description | 引導使用者完成結構化文件共同撰寫的工作流程。當使用者想撰寫文件、提案、技術規格書、決策文件或類似的結構化內容時使用。此工作流程幫助使用者有效傳遞上下文、透過迭代精煉內容，並驗證文件對讀者是否有效。當使用者提到撰寫文件、建立提案、草擬規格書或類似文件任務時觸發。 |
此技能提供一個結構化的工作流程，指導使用者完成協作式文件建立。作為積極的引導者，帶領使用者經歷三個階段：上下文收集、精煉與結構化、以及讀者測試。
觸發條件：
初始提供： 向使用者提供一套結構化的文件共同撰寫工作流程。解釋三個階段：
解釋此方法有助於確保文件在他人閱讀時（包括當他們將文件貼入 Claude 時）能良好運作。詢問是否要嘗試此工作流程或偏好自由撰寫。
如果使用者拒絕，則自由撰寫。如果使用者接受，進入階段 1。
目標： 縮小使用者所知與 Claude 所知之間的差距，以便後續能提供聰明的指導。
先向使用者詢問關於文件的後設資訊：
告知他們可以用簡短方式回答或以最方便的方式傾倒資訊。
如果使用者提供範本或提及文件類型：
如果使用者提及編輯現有的共享文件：
初始問題回答後，鼓勵使用者傾倒所有他們擁有的上下文。要求資訊如：
建議他們不用擔心組織 — 先把所有東西倒出來。提供多種上下文提供方式：
如果整合可用（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 伺服器），提到這些可用於直接提取上下文。
如果未偵測到整合且在 Claude.ai 或 Claude 應用程式中： 建議他們可以在 Claude 設定中啟用連接器，以便直接從通訊應用程式和文件儲存中提取上下文。
告知他們完成初始傾倒後會提出釐清問題。
在上下文收集期間：
如果使用者提到團隊頻道或共享文件：
如果使用者提到不熟悉的實體/專案：
隨著使用者提供上下文，追蹤已學到的內容和仍不清楚的部分
提出釐清問題：
當使用者表示已完成初始傾倒（或在提供大量上下文後），提出釐清問題以確保理解：
根據上下文中的空白生成 5-10 個編號問題。
告知他們可以用簡短方式回答（例如：「1: 是、2: 見 #頻道、3: 不行因為向後相容」），連結至更多文件、指向頻道閱讀，或繼續傾倒資訊。以最有效率的方式即可。
退出條件： 當問題展現出理解時，即已收集足夠上下文 — 當能夠提出關於邊緣案例和權衡的問題，而不需要解釋基本概念時。
轉場： 詢問在此階段是否還有更多上下文要提供，或者是否該進入文件撰寫了。
如果使用者想要添加更多，讓他們繼續。準備好後，進入階段 2。
目標： 透過腦力激盪、策劃和迭代精煉，逐章節建構文件。
給使用者的說明： 解釋將逐章節建構文件。每個章節的流程：
從未知最多的章節開始（通常是核心決策/提案），然後處理其餘部分。
章節排序：
如果文件結構明確： 詢問他們想從哪個章節開始。
建議從未知最多的章節開始。對於決策文件，通常是核心提案。對於規格書，通常是技術方法。摘要章節最好留到最後。
如果使用者不知道需要哪些章節： 根據文件類型和範本，建議 3-5 個適合的章節。
詢問此結構是否可行，或是否要調整。
結構確定後：
以佔位文字建立所有章節的初始文件結構。
如果可使用產出物：
使用 create_file 建立產出物。這為 Claude 和使用者提供了一個可依循的架構。
告知將建立包含所有章節佔位符的初始結構。
建立產出物，包含所有章節標題和簡短佔位文字如「[待撰寫]」或「[內容放這裡]」。
提供架構連結並指示該開始填寫每個章節了。
如果無法使用產出物：
在工作目錄中建立一個 markdown 檔案。適當命名（例如：decision-doc.md、technical-spec.md）。
告知將建立包含所有章節佔位符的初始結構。
建立檔案，包含所有章節標題和佔位文字。
確認檔名已建立並指示該開始填寫每個章節了。
每個章節的流程：
宣布將開始撰寫 [章節名稱] 章節。詢問 5-10 個關於應包含什麼的釐清問題：
根據上下文和章節目的生成 5-10 個特定問題。
告知他們可以用簡短方式回答或僅指出重要的涵蓋內容。
對於 [章節名稱] 章節，腦力激盪 [5-20] 個可能包含的內容，取決於章節的複雜度。尋找：
根據章節複雜度生成 5-20 個編號選項。結尾時提供如果需要更多選項可繼續腦力激盪。
詢問哪些要點要保留、移除或合併。要求簡短理由以幫助學習後續章節的優先順序。
提供範例：
如果使用者給出自由形式的回饋（例如：「看起來不錯」或「我喜歡大部分但是...」）而非編號選擇，提取他們的偏好並繼續。解析他們想保留/移除/更改的內容並套用。
根據他們所選的，詢問 [章節名稱] 章節是否有遺漏重要內容。
使用 str_replace 將此章節的佔位文字替換為實際撰寫的內容。
宣布將根據他們的選擇撰寫 [章節名稱] 章節的草稿。
如果使用產出物： 撰寫後，提供產出物連結。
請他們閱讀並指出要更改的地方。說明越具體越有助於後續章節的學習。
如果使用檔案（無產出物）： 撰寫後，確認完成。
告知 [章節名稱] 章節已撰寫於 [檔名]。請他們閱讀並指出要更改的地方。說明越具體越有助於後續章節的學習。
給使用者的關鍵說明（在撰寫第一個章節時包含）： 提供注意：不要直接編輯文件，而是指出要更改的地方。這有助於學習他們的風格以用於後續章節。例如：「移除 X 項目符號 — 已被 Y 涵蓋」或「讓第三段更簡潔」。
隨著使用者提供回饋：
str_replace 進行編輯（永不重新列印整份文件）繼續迭代直到使用者對章節感到滿意。
連續 3 次迭代沒有實質性更改後，詢問是否有任何可以在不遺失重要資訊的情況下移除的內容。
當章節完成時，確認 [章節名稱] 已完成。詢問是否準備好進入下一章節。
對所有章節重複此流程。
接近完成時（80%+ 的章節已完成），宣布打算重新閱讀整份文件並檢查：
閱讀整份文件並提供回饋。
當所有章節都已撰寫和精煉： 宣布所有章節已撰寫完畢。指出打算再次審閱完整文件。
審閱整體連貫性、流暢度、完整性。
提供任何最終建議。
詢問是否準備好進入讀者測試，或是否還要精煉任何內容。
目標： 使用全新的 Claude（無上下文洩漏）測試文件，以驗證它對讀者有效。
給使用者的說明： 解釋現在要測試文件是否真的對讀者有效。這能抓出盲點 — 對作者來說有意義但可能讓他人困惑的內容。
如果可使用子代理（例如在 Claude Code 中）：
直接執行測試，無需使用者參與。
宣布打算預測讀者在試圖發現此文件時可能會提出什麼問題。
生成 5-10 個讀者實際會提出的問題。
宣布將使用全新的 Claude 實例（沒有此對話的上下文）測試這些問題。
對每個問題，使用僅包含文件內容和問題的子代理。
摘要讀者 Claude 對每個問題的正確/錯誤之處。
宣布將執行額外檢查。
使用子代理檢查歧義、錯誤假設、矛盾。
摘要發現的任何問題。
如果發現問題： 報告讀者 Claude 在特定問題上遇到困難。
列出具體問題。
指出打算修復這些差距。
回到精煉階段處理有問題的章節。
如果無法使用子代理（例如 claude.ai 網頁介面）：
使用者需要手動測試。
詢問人們在試圖發現此文件時可能會問什麼問題。他們會在 Claude.ai 中輸入什麼？
生成 5-10 個讀者實際會提出的問題。
提供測試說明：
對每個問題，指示讀者 Claude 提供：
檢查讀者 Claude 是否給出正確答案或誤解了什麼。
也詢問讀者 Claude：
詢問讀者 Claude 答錯了什麼或在哪些地方遇到困難。指出打算修復那些差距。
回到精煉階段處理任何有問題的章節。
當讀者 Claude 能一致地正確回答問題且不再浮出新的差距或歧義時，文件即已就緒。
當讀者測試通過時： 宣布文件已通過讀者 Claude 測試。在完成前：
詢問是否要再做一次審閱，或工作已完成。
如果使用者要求最終審閱，提供。否則： 宣布文件完成。提供幾個最終提示：
語氣：
處理偏離：
上下文管理：
產出物管理：
create_file 撰寫完整章節str_replace 進行所有編輯品質優先於速度：