doc-coauthoring 适合写技术方案、决策记录、产品提案和需要反复沟通的文档。它的重点是把你脑中的背景转移给写作伙伴，再检查成文后别人是否能独立理解。它不只是润色语句，也不默认生成 Word 文件；需要 DOCX 时，可以在内容稳定后另做文件排版。
安装与调用
在 Claude Code 的聊天输入框依次发送下面两条命令。这是插件命令，不是在系统终端运行的 Shell 命令；第二条安装的是包含 doc-coauthoring 的官方技能包。
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
安装后，在同一项目的会话里明确说“使用 doc-coauthoring”，再提供文件或任务。下面的提示词是可修改的首次输入示例。安装会加入技能说明与资源；它不会替你准备输入资料，也不代表所有依赖已经在本机安装。若找不到技能，先检查插件是否安装并启用，以及会话是否已加载最新插件，再继续任务。
用一个真实决策开始
先给受众和要做出的决定，而不是只说“帮我写专业一点”：
使用 doc-coauthoring 写一份是否替换内部搜索系统的决策文档。
读者是技术负责人和运营团队，目标是决定是否开始两周原型。
我会提供现状、三种方案和成本估算。先找背景缺口，再逐节起草。
未知的数据标为待补，不要把假设写成已经完成的测试结果。
第一阶段会确认文档类型、主要读者、期望影响、模板和限制。你可以先不整理材料，把会议记录、方案优缺点和已有数字一起交给 Agent。随后回答它根据缺口提出的问题；如果只能给结论却说不出依据，应保留这个空缺。共享链接不可读时，直接提供相关段落通常比反复尝试一个未接通的连接器更有效。
第二阶段按章节推进。对于决策文档，先写最不确定的核心取舍，再补背景与摘要。Agent 可以列出候选论点，你选择保留、合并或删除的部分，然后只修改对应段落。这比每轮重写整篇更容易看清哪些决定变了，也能减少已经确认的事实被意外改动。
用陌生读者的问题验收
初稿完成后，给一段没有参与前面讨论的新会话，只提供文档本身，请它回答“为什么现在做”“有哪些替代方案”“两周后如何决定继续”。支持子代理的宿主可代为执行这一检查；否则自己开新会话即可。读者回答不出来时，先修改正文中的缺失信息，不要只在聊天里解释一次就算完成。
这一步检查的是可理解性。模型流畅地复述方案，并不能证明成本数字、法务判断或系统性能真实正确；这些仍要由对应材料和负责人确认。交付时保留成文内容、待决事项和原始资料链接，让下一位读者知道哪些选择已定、哪些仍是研究问题。
如果只需要一封很短的通知，可以明确跳过完整三阶段流程。若团队已有固定模板，应在开始时提供，避免结构成形后才要求全部重排。对于图片承担关键信息的文档，还应补充图注或文字说明，让只读文字的读者也能理解其结论。
让“待补”成为可执行的问题
整理背景时，给每条数字和判断标出来源及负责人：例如成本是财务估算、使用量来自现有报表、性能还未测试。让 Agent 把缺口改写成具体问题：“谁能确认迁移成本？”“试点失败的阈值是什么？”这比在文档里留下十几个笼统的“待完善”更便于推进。
进入读者测试时，挑一位没有参与起草的人或一个新会话，只给最终文档，不给聊天背景。要求他复述决策、依据和未决风险，并指出哪段无法支持结论。若回答必须靠你口头补充，优先改正文；若问题来自确实不存在的数据，就保留为决策前条件。
三阶段何时可以跳过
如果你已有完整资料和固定模板，可以请 Agent 简短确认读者与目的后直接起草，再保留读者测试。若材料非常散，先进入信息倾倒与提问，不要过早要求完整正文。对时间敏感的决策文档，可先写一页决策摘要，列出现状、选项、建议与待验证条件，再扩展成正式版本。无论采用哪条路径，最后都检查读者能否只凭文件本身理解取舍；聊天里达成共识但文档里没写，交付仍然不完整。
不要把第一轮提问当作交付
这套流程需要你回答背景问题，再让 Agent 整理结构和写入文件。一次独立的单轮任务测量中，Skill 被调用的运行都停在提问阶段，没有写出指定文档。因此，如果你在 CI 或一次性脚本里用它，应提供可继续回复的交互环节；如果任务必须单轮完成且立即产出文档，就不要依赖这个需要问答的 Skill；改用普通写稿任务，直接给出完整资料、允许的假设和输出路径，最后检查文件确实存在。