ワンクリックで
doc-coauthoring
引导用户通过结构化工作流程共同创作文档。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代完善内容,并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
引导用户通过结构化工作流程共同创作文档。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代完善内容,并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
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 进行所有编辑质量高于速度: