claudeskills文档文档共同创作
指导用户完成共同创作文档的结构化工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流程可帮助用户高效地传输上下文、通过迭代细化内容并验证文档是否适合读者。当用户提到编写文档、创建提案、起草规范或类似的文档任务时触发。
来源：内容改编自人类/技能（麻省理工学院）。
该技能提供了一个结构化的工作流程，用于指导用户完成协作文档创建。作为积极的指南，引导用户经历三个阶段：上下文收集、细化和结构以及读者测试。
何时提供此工作流程
触发条件：
- 用户提到编写文档：“编写文档”、“起草提案”、“创建规范”、“编写”
- 用户提及特定文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
- 用户似乎正在开始一项实质性的写作任务
初始报价： 为用户提供共同创作文档的结构化工作流程。解释一下这三个阶段：
- 上下文收集：用户提供所有相关上下文，而克劳德提出澄清问题
- 细化和结构：通过头脑风暴和编辑迭代构建每个部分
- 读者测试：用新鲜的克劳德（没有上下文）测试文档，以在其他人阅读之前发现盲点
解释这种方法有助于确保文档在其他人阅读时（包括将其粘贴到 Claude 中时）正常工作。询问他们是否想尝试此工作流程还是更喜欢自由工作。
如果用户拒绝，则自由工作。如果用户接受，则进入第 1 阶段。
第一阶段：背景收集
目标： 缩小用户所知道的内容与 Claude 所知道的内容之间的差距，从而在以后实现智能指导。
最初的问题
首先询问用户有关文档的元上下文：
- 这是什么类型的文档？ （例如，技术规范、决策文档、提案）
- 主要受众是谁？
- 当有人读到这篇文章时，期望产生什么影响？
- 是否有可遵循的模板或特定格式？
- 还有其他限制或背景需要了解吗？
告诉他们可以用速记方式回答或转储信息，但最适合他们。
如果用户提供模板或提及文档类型：
- 询问他们是否有模板文档可以分享
- 如果他们提供共享文档的链接，请使用适当的集成来获取它
- 如果他们提供文件，请阅读它
如果用户提到编辑现有共享文档：
- 使用适当的积分来读取当前状态
- 检查没有替代文本的图像
- 如果图像存在而没有替代文本，请解释当其他人使用 Claude 来理解文档时，Claude 将无法看到它们。询问他们是否想要生成替代文本。如果是这样，请要求他们将每个图像粘贴到聊天中以生成描述性替代文本。
信息转储
一旦回答了最初的问题，鼓励用户转储他们拥有的所有上下文。请求信息，例如：
- 项目/问题的背景
- 相关团队讨论或共享文档
- 为什么没有使用替代解决方案
- 组织背景（团队动态、过去的事件、政治）
- 时间压力或限制
- 技术架构或依赖关系
- 利益相关者的担忧
建议他们不要担心如何组织它——只要把它全部拿出来就可以了。提供多种方式来提供上下文：
- 信息转储意识流
- 指向团队频道或线程进行阅读
- 共享文档的链接
如果集成可用（例如，Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），请提及这些可用于直接拉入上下文。
如果在 Claude.ai 或 Claude 应用程序中未检测到集成： 建议他们可以在 Claude 设置中启用连接器，以允许直接从消息传递应用程序和文档存储中提取上下文。
通知他们在完成初始转储后将询问澄清问题。
在上下文收集期间：
-
如果用户提到团队频道或共享文档：
- 如果集成可用：通知他们现在将阅读内容，然后使用适当的集成
- 如果集成不可用：解释缺乏访问权限。建议他们在克劳德设置中启用连接器，或者直接粘贴相关内容。
-
如果用户提到未知的实体/项目：
- 询问是否应该搜索连接的工具以了解更多信息
- 搜索前等待用户确认
-
当用户提供上下文时，跟踪正在学习的内容和尚不清楚的内容
提出澄清问题：
当用户表示他们已完成初始转储（或在提供大量上下文后）时，请提出澄清问题以确保理解：
根据上下文中的空白生成 5-10 个编号问题。
告诉他们可以使用速记来回答（例如，“1：是，2：参见#channel，3：否，因为向后兼容”），链接到更多文档，指向要阅读的频道，或者只是继续信息转储。对他们来说最有效的方式。
退出条件： 当问题表现出理解时，即可以询问边缘情况和权衡而不需要解释基础知识时，就已经收集了足够的背景信息。
过渡： 询问他们现阶段是否想提供更多背景信息，或者是否需要继续起草文档。
如果用户想要添加更多，就让他们添加吧。准备就绪后，进入第 2 阶段。
第二阶段：细化和结构
目标： 通过集思广益、策划和迭代细化逐节构建文档。
用户说明： 解释该文档将逐节构建。对于每个部分：
- 将询问要包含哪些内容的澄清问题
- 将集思广益 5-20 个选项
- 用户将指示要保留/删除/合并的内容
- 本节将起草
- 它将通过手术编辑进行完善
从未知数最多的部分开始（通常是核心决策/提案），然后完成其余部分。
章节排序：
如果文档结构清晰： 询问他们想从哪个部分开始。
建议从未知数最多的部分开始。对于决策文档，这通常是核心提案。对于规格，通常是技术方法。摘要部分最好留到最后。
如果用户不知道他们需要哪些部分： 根据文档和模板的类型，建议适合文档类型的 3-5 个部分。
询问这个结构是否有效，或者他们是否想要调整它。
一旦结构达成一致：
使用所有部分的占位符文本创建初始文档结构。
如果可以访问工件：
使用create_file创建工件。这为克劳德和用户提供了一个工作的脚手架。
通知他们将创建带有所有部分占位符的初始结构。
创建包含所有节标题和简短占位符文本（例如“[待写入]”或“[此处内容]”）的工件。
提供脚手架链接并指出是时候填写每个部分了。
如果无法访问工件：
在工作目录中创建一个 markdown 文件。适当命名（例如，decision-doc.md、technical-spec.md）。
通知他们将创建带有所有部分占位符的初始结构。
创建包含所有节标题和占位符文本的文件。
确认文件名已创建，并指示是时候填写每个部分了。
对于每个部分：
第 1 步：澄清问题
宣布将在 [SECTION NAME] 部分开始工作。问 5-10 个关于应包含哪些内容的澄清问题：
根据上下文和部分目的生成 5-10 个具体问题。
告诉他们可以用速记方式回答，或者只指出需要涵盖的重要内容。
第二步：头脑风暴
对于 [SECTION NAME] 部分，集思广益 [5-20] 可能包含的内容，具体取决于该部分的复杂性。寻找：
- 可能已被遗忘的共享上下文
- 尚未提及的角度或考虑因素
根据部分复杂性生成 5-20 个编号选项。最后，如果他们想要更多选择，请进行更多的头脑风暴。
第三步：策展
询问哪些点应该保留、删除或合并。要求简要说明理由，以帮助了解下一节的优先事项。
提供示例：
- “保留1、4、7、9”
- “删除 3 个（重复 1 个）”
- “删除6（观众已经知道这一点）”
- “合并 11 和 12”
如果用户提供自由形式的反馈（例如，“看起来不错”或“我喜欢其中大部分内容，但是......”）而不是编号的选择，请提取他们的偏好并继续。解析他们想要保留/删除/更改的内容并应用它。
第 4 步：间隙检查
根据他们的选择，询问 [SECTION NAME] 部分是否缺少任何重要内容。
第五步：起草
使用str_replace将此部分的占位符文本替换为实际起草的内容。
宣布现在将根据他们的选择起草[部分名称]部分。
如果使用工件： 起草后，提供工件的链接。
请他们通读并指出要更改的内容。请注意，具体有助于学习接下来的部分。
如果使用文件（无工件）： 起草完毕后，确认完成。
通知他们 [SECTION NAME] 部分已在 [文件名] 中起草。请他们通读并指出要更改的内容。请注意，具体有助于学习接下来的部分。
用户关键说明（包括起草第一部分时）： 提供注释：不要直接编辑文档，而是要求他们指出要更改的内容。这有助于学习他们的风格以供将来的部分使用。例如：“删除 X 项目符号 - 已被 Y 覆盖”或“使第三段更简洁”。
第 6 步：迭代细化
当用户提供反馈时：
- 使用
str_replace进行编辑（切勿重新打印整个文档） - 如果使用工件： 每次编辑后提供指向工件的链接
- 如果使用文件： 只需确认编辑已完成
- 如果用户直接编辑文档并要求阅读它：在心里记下他们所做的更改，并在以后的部分中记住它们（这显示了他们的偏好）
继续迭代直到用户对该部分感到满意。
质量检查
在连续 3 次迭代没有发生实质性变化后，询问是否可以删除任何内容而不丢失重要信息。
部分完成后，确认 [SECTION NAME] 已完成。询问是否准备好进入下一部分。
对所有部分重复此操作。
即将完成
随着接近完成（已完成 80% 以上的部分），宣布打算重新阅读整个文档并检查：
- 各部分的流动性和一致性
- 冗余或矛盾
- 任何感觉像“溢出”或通用填充物的东西
- 每句话是否都有分量
阅读整个文档并提供反馈。
当所有部分都起草和完善后： 宣布所有章节均已起草。表明有意再次审阅完整文档。
检查整体连贯性、流畅性、完整性。
提供任何最终建议。
询问他们是否准备好进行读者测试，或者是否想要完善其他内容。
第三阶段：读者测试
目标： 使用新的 Claude 测试该文档（无上下文出血），以验证它是否适合读者。
用户说明： 说明现在将进行测试以查看该文档是否真正适合读者。这抓住了盲点——对作者来说有意义但可能让其他人感到困惑的事情。
测试方法
如果可以访问子代理（例如，在克劳德代码中）：
直接执行测试，无需用户参与。
第 1 步：预测读者问题
宣布意图预测读者在尝试发现此文档时可能会提出哪些问题。
提出 5-10 个读者会实际提出的问题。
第 2 步：使用子代理进行测试
宣布这些问题将使用新的克劳德实例进行测试（此对话中没有上下文）。
对于每个问题，仅使用文档内容和问题调用子代理。
总结读者克劳德对每个问题的正确/错误。
第 3 步：运行额外检查
宣布将进行额外检查。
调用子代理来检查是否存在歧义、错误假设和矛盾。
总结发现的问题。
第 4 步：报告并修复
如果发现问题： 报告读者克劳德在具体问题上遇到了困难。
列出具体问题。
表明修复这些差距的意图。
循环回细化有问题的部分。
如果无法访问子代理（例如 claude.ai Web 界面）：
用户需要手动进行测试。
第 1 步：预测读者问题
询问人们在尝试发现此文档时可能会问哪些问题。他们会在 Claude.ai 中输入什么？
提出 5-10 个读者会实际提出的问题。
第 2 步：设置测试
提供测试说明：
- 打开新的克劳德对话：https://claude.ai
- 粘贴或共享文档内容（如果使用启用了连接器的共享文档平台，请提供链接）
- 向读者克劳德询问生成的问题
对于每个问题，指示读者 Claude 提供：
- 答案
- 是否有任何内容含糊或不清楚
- 文档假设的知识/背景是已知的
检查读者克劳德是否给出了正确答案或误解了任何内容。
第 3 步：额外检查
另请教读者克劳德：
- “这份文档中的哪些内容可能对读者来说是不明确或不清楚的？”
- “本文档假设读者已经具备哪些知识或背景？”
- “有没有什么内部矛盾或者不一致的地方？”
第 4 步：根据结果进行迭代
询问读者克劳德犯了什么错误或遇到了什么困难。表明有意弥补这些差距。
循环回细化任何有问题的部分。
退出条件（两种方法）
当读者克劳德始终正确地回答问题并且没有出现新的差距或歧义时，文档就准备好了。
最终审查
当读者测试通过时： 宣布该文档已通过 Reader Claude 测试。完成前：
- 建议他们自己进行最终通读 - 他们拥有此文档并对其质量负责
- 建议仔细检查任何事实、链接或技术细节
- 要求他们验证它是否达到了他们想要的效果
询问他们是否需要再进行一次审查，或者工作是否完成。
如果用户想要最终审核，请提供。否则： 宣布文件完成。提供一些最后的提示：
- 考虑在附录中链接此对话，以便读者可以了解该文档是如何开发的
- 使用附录提供深度而不会使主文档变得臃肿
- 当收到真实读者的反馈时更新文档
有效指导的技巧
语气：
- 直接且程序化
- 当它影响用户行为时，简要解释其原理
- 不要试图“推销”该方法——只需执行它
处理偏差：
- 如果用户想跳过一个阶段：询问他们是否想跳过此阶段并编写自由格式
- 如果用户看起来很沮丧：承认这花费的时间比预期的要长。建议加快行动速度的方法
- 始终给予用户调整流程的代理权
上下文管理：
- 在整个过程中，如果所提到的内容缺少上下文，请主动询问
- 不要让差距不断累积——出现时立即解决
工件管理：
- 使用
create_file起草完整部分 - 使用
str_replace进行所有编辑 - 每次更改后提供工件链接
- 切勿使用工件进行头脑风暴列表 - 这只是对话
质量胜于速度：
- 不要急于完成各个阶段
- 每次迭代都应该做出有意义的改进
- 目标是一份真正适合读者的文档
参见 GitHub
网络应用程序测试
用于基于 Playwright 的 Web 应用程序测试的代理技能手册，其中包含服务器编排助手和故障排除提示。
文档
每当用户想要创建、阅读、编辑或操作 Word 文档（.docx 文件）时，请使用此技能。触发因素包括：提及“Word doc”、“word 文档”、“.docx”，或要求生成具有目录、标题、页码或信头等格式的专业文档。还可以在从.docx 文件中提取或重新组织内容、在文档中插入或替换图像、在 Word 文件中执行查找和替换、处理跟踪的更改或注释或将内容转换为精美的 Word 文档时使用。如果用户要求“报告”、“备忘录”、“信件”、“模板”或类似的 Word 或.docx 文件形式的可交付成果，请使用此技能。请勿用于 PDF、电子表格、Google 文档或与文档生成无关的一般编码任务。