القائمة
引导用户通过结构化工作流程共同创作文档。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代完善内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
创建高质量 MCP (Model Context Protocol) 服务器的指南，使 LLM 能够通过精心设计的工具与外部服务交互。用于构建 MCP 服务器以集成外部 API 或服务，支持 Python (FastMCP) 或 Node/TypeScript (MCP SDK)。
使用 p5.js 创建算法艺术，具有种子随机性和交互式参数探索。当用户请求使用代码创建艺术、生成艺术、算法艺术、流场或粒子系统时使用此技能。创作原创算法艺术而非复制现有艺术家的作品以避免版权侵权。
将 Anthropic 官方品牌颜色和字体应用于任何可能受益于 Anthropic 外观和感觉的产物。当需要应用品牌颜色、样式指南、视觉格式或公司设计标准时使用。
使用设计哲学在 .png 和 .pdf 文档中创建精美的视觉艺术。当用户要求创建海报、艺术作品、设计或其他静态作品时应使用此技能。创作原创视觉设计，绝不复制现有艺术家的作品以避免侵犯版权。
当用户想要创建、读取、编辑或操作 Word 文档（.docx 文件）时使用此技能。触发条件包括：任何提及「Word 文档」、「word document」、「.docx」，或请求生成带有格式化内容（如目录、标题、页码或信头）的专业文档。当从 .docx 文件中提取或重组内容、在文档中插入或替换图片、在 Word 文件中执行查找替换、处理修订或批注，或将内容转换为精美的 Word 文档时也应使用。如果用户要求生成「报告」、「备忘录」、「信函」、「模板」或类似的 Word 或 .docx 文件交付物，请使用此技能。不要用于 PDF、电子表格、Google Docs 或与文档生成无关的通用编码任务。
创建独特的、生产级别的前端界面，具有高设计质量。当用户要求构建 Web 组件、页面、artifact、海报或应用程序时使用此技能（示例包括网站、落地页、仪表板、React 组件、HTML/CSS 布局，或者在美化任何 Web UI 时）。生成富有创意、精致的代码和 UI 设计，避免通用的 AI 美学。
| 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 进行所有编辑质量高于速度：