원클릭으로
doc-coauthoring
引导用户通过结构化工作流共同撰写文档。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流帮助用户高效传递上下文、通过迭代精炼内容,并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
引导用户通过结构化工作流共同撰写文档。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流帮助用户高效传递上下文、通过迭代精炼内容,并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
当用户需要创建、读取、编辑或转换 Word 文档(.docx)时必须使用本技能。触发场景包括:提到 Word/docx、报告/备忘录/正式函件输出、目录和页眉页脚、批注或修订模式、替换文档内容、插入或替换图片、从 docx 提取结构化内容等。若目标交付物是 .docx,本技能应优先触发。不要用于 PDF、电子表格、Google Docs API 或无关编程任务。
只要任务涉及 PDF 输入或输出,就应优先使用本技能。包括:读取/抽取文本与表格、合并拆分、旋转页面、加水印、创建新 PDF、填写表单、加解密、提取图片、扫描件 OCR 等。用户提到 `.pdf` 文件名或要求交付 PDF 时都应触发。
只要任务与 .pptx 有关(输入、输出或两者都有),就应触发本技能。包括:创建演示文稿、读取提取内容、修改现有模板、合并拆分页面、处理版式/讲稿/批注等。用户提到 deck/slides/presentation 或具体 .pptx 文件时,即便最终用途是摘要或邮件,也应使用本技能。
当用户任务以电子表格文件为核心输入或输出时必须使用本技能。涵盖 .xlsx/.xlsm/.csv/.tsv 的读取、清洗、修复、建模、公式计算、格式化、图表、模板更新与格式转换。用户只要提到某个表格文件路径并要求处理或产出表格,都应触发本技能。若主要交付物不是电子表格(如 Word/HTML/数据库流水线/Google Sheets API 集成),则不应触发。
创建新 skills、改造已有 skills、并通过评测闭环持续优化。用户只要提到“做一个 skill”“改造 skill”“跑评测/benchmark”“验证 skill 效果”“优化 description 触发率”等场景,都应优先使用此技能。
使用 p5.js 创建具有确定性随机和交互式参数探索的算法艺术。当用户请求使用代码创作艺术、生成式艺术、算法艺术、流场或粒子系统时使用此技能。创建原创的算法艺术而非复制现有艺术家的作品,以避免版权侵犯。
SOC 직업 분류 기준
| 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 文件。适当命名(例如,决策文档.md、技术规范.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 进行所有编辑质量重于速度: