القائمة
引導使用者完成結構化文件共同撰寫的工作流程。當使用者想撰寫文件、提案、技術規格書、決策文件或類似的結構化內容時使用。此工作流程幫助使用者有效傳遞上下文、透過迭代精煉內容，並驗證文件對讀者是否有效。當使用者提到撰寫文件、建立提案、草擬規格書或類似文件任務時觸發。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
使用 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 進行所有編輯品質優先於速度：