菜单
引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/linxuan-sys/opencode-skills-chinese --skill doc-coauthoring命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
任何时候只要涉及.pptx文件——无论是作为输入、输出还是两者兼有——就使用此技能。这包括：创建幻灯片、推介文件或演示文稿；读取、解析或提取任何.pptx文件中的文本（即使提取的内容将用于其他地方，比如邮件或摘要）；编辑、修改或更新现有演示文稿；合并或拆分幻灯片文件；处理模板、布局、演讲者备注或注释。只要用户提到"deck"、"slides"、"presentation"或引用.pptx文件名，无论他们后续打算如何处理内容，都要触发此技能。如果需要打开、创建或处理.pptx文件，使用此技能。
使用p5.js创建带有种子随机和交互式参数探索的算法艺术。当用户请求使用代码创建艺术、生成艺术、算法艺术、流场或粒子系统时使用此技能。创建原创算法艺术，而不是复制现有艺术家的作品，以避免侵犯版权。
当用户需要创建、读取、编辑或操作Word文档（.docx文件）时使用本技能。触发场景包括：任何提及'Word doc'、'word document'、'.docx'的内容，或生成带目录、标题、页码、信头格式的专业文档的需求。也适用于从.docx文件提取或重组内容、在文档中插入或替换图片、在Word文件中执行查找替换、处理修订或评论、或将内容转换为精美Word文档的场景。如果用户要求生成Word或.docx格式的'报告'、'备忘录'、'信件'、'模板'或类似交付物，使用本技能。请勿用于PDF、电子表格、Google Docs或与文档生成无关的通用编码任务。
基于 SOC 职业分类
正在显示 SKILL.md
| name | doc-coauthoring |
| description | 引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。 |
此技能提供了一个结构化的工作流程，用于指导用户完成协作文档创建。作为主动引导，引导用户完成三个阶段：上下文收集、优化与结构化、以及读者测试。
触发条件：
初始提供： 向用户提供结构化的文档协作工作流程。解释三个阶段：
解释这种方法有助于确保文档在他人阅读时效果良好（包括当他们将其粘贴到 Opencode 中时）。询问他们是否想尝试此工作流程或更喜欢自由形式工作。
如果用户拒绝，自由形式工作。如果用户接受，进入阶段 1。
目标： 缩小用户知道的和 Opencode 知道的之间的差距，使后续能够提供智能指导。
首先询问用户关于文档的元上下文：
告诉他们可以用简写回答，或者以任何最适合他们的方式转储信息。
如果用户提供模板或提到文档类型：
如果用户提到编辑现有的共享文档：
一旦初始问题得到回答，鼓励用户转储他们拥有的所有上下文。请求信息如：
建议他们不要担心组织它——只是把它们都倒出来。提供多种方式来提供上下文：
如果集成可用可以直接使用这些来拉入上下文。
告诉他们一旦完成初始转储，将会提出澄清问题。
在上下文收集期间：
如果用户提到团队频道或共享文档：
如果用户提到未知的实体/项目：
当用户提供上下文时，跟踪已学到的内容和仍不清楚的内容
提出澄清问题：
当用户表明已完成初始转储（或在提供大量上下文后），提出澄清问题以确保理解：
根据上下文中的差距生成 5-10 个编号问题。
告诉他们可以用简写回答（例如，"1: 是，2: 否，3:其他说明 "），链接到更多文档，指向要阅读的频道，或者只是继续信息转储。任何对他们最有效的方式。
退出条件： 当问题显示出理解时，已收集足够的上下文——当可以询问边缘情况和权衡而不需要解释基础知识时。
过渡： 询问在此阶段是否还有更多上下文要提供，或者是否该开始起草文档。
如果用户想添加更多，让他们添加。准备好后，进入阶段 2。
目标： 通过头脑风暴、策划和迭代优化逐部分构建文档。
给用户的说明： 解释文档将逐部分构建。对于每个部分：
从未知数最多的部分开始（通常是核心决策/提案），然后处理其余部分。
部分排序：
如果文档结构清晰： 询问他们想从哪个部分开始。
建议从未知数最多的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。总结部分最好留到最后。
如果用户不知道他们需要什么部分： 根据文档类型和模板，建议 3-5 个适合文档类型的部分。
询问此结构是否有效，或者他们是否想调整它。
一旦结构达成一致：
创建带有所有部分占位符文本的初始文档结构。
如果可以访问 artifacts： 创建 artifact。这给 Opencode 和用户一个可以工作的脚手架。
告诉他们将创建带有所有部分占位符的初始结构。
创建包含所有部分标题和简短占位符文本（如"[待编写]"或"[内容在此]"）的 artifact。
提供脚手架链接并表明是时候填写每个部分了。
如果无法访问 artifacts：
在工作目录中创建 markdown 文件。适当命名（例如，decision-doc.md、technical-spec.md）。
告诉他们将创建带有所有部分占位符的初始结构。
创建包含所有部分标题和占位符文本的文件。
确认文件名已创建并表明是时候填写每个部分了。
对于每个部分：
宣布将开始处理 [部分名称] 部分。提出 5-10 个关于应包含什么的澄清问题：
根据上下文和部分目的生成 5-10 个具体问题。
告诉他们可以用简写回答或只是指出什么重要。
对于 [部分名称] 部分，头脑风暴 5-20 件可能包含的内容，取决于部分的复杂性。寻找：
根据部分复杂性生成 5-20 个编号选项。最后，如果他们想要更多选项，提供头脑风暴更多。
询问哪些点应保留、删除或合并。请求简短的理由以帮助学习下一部分的优先级。
提供示例：
如果用户给出自由形式反馈（例如，"看起来不错"或"我喜欢大部分但是..."）而不是编号选择，提取他们的偏好并继续。解析他们想要保留/删除/更改的内容并应用它。
根据他们选择的内容，询问 [部分名称] 部分是否缺少任何重要内容。
将该部分的占位符文本替换为实际起草的内容。
宣布现在将根据他们选择的内容起草 [部分名称] 部分。
如果使用 artifacts： 起草后，提供 artifact 的链接。
让他们通读并指出要更改什么。注意具体说明有助于为下一部分学习。
如果使用文件（无 artifacts）： 起草后，确认完成。
告诉他们 [部分名称] 部分已在 [文件名] 中起草。让他们通读并指出要更改什么。注意具体说明有助于为下一部分学习。
用户的关键说明（在起草第一部分时包含）： 提供说明：不要直接编辑文档，让他们指出要更改什么。这有助于学习他们的风格以用于后续部分。例如："删除 X 要点——已被 Y 覆盖"或"使第三段更简洁"。
当用户提供反馈时：
继续迭代 直到用户对该部分满意。
在连续 3 次迭代没有实质性更改后，询问是否可以在不丢失重要信息的情况下删除任何内容。
当部分完成时，确认 [部分名称] 已完成。询问是否准备好进入下一部分。
对所有部分重复。
当接近完成时（80%+ 的部分完成），宣布打算重新阅读整个文档并检查：
阅读整个文档并提供反馈。
当所有部分都起草和优化后： 宣布所有部分都已起草。表明打算最后一次审查完整文档。
审查整体连贯性、流畅性、完整性。
提供任何最终建议。
询问是否准备好进入读者测试，或者他们是否想进一步优化任何内容。
目标： 用全新的 Opencode（无上下文污染）测试文档，验证它对读者是否有效。
给用户的说明： 解释现在将测试文档是否真的对读者有效。这可以发现盲点——对作者有意义但可能让其他人困惑的事情。
如果可以访问子代理（例如，在 Opencode 中）：
直接执行测试，无需用户参与。
宣布打算预测读者在尝试发现此文档时可能会问什么问题。
生成 5-10 个读者会实际提出的问题。
宣布将用全新的 Opencode 实例（无此对话的上下文）测试这些问题。
对于每个问题，用仅文档内容和问题调用子代理。
总结读者 Opencode 对每个问题的对错。
宣布将执行额外检查。
调用子代理检查歧义、错误假设、矛盾。
总结发现的任何问题。
如果发现问题： 报告读者 Opencode 在特定问题上遇到困难。
列出具体问题。
表明打算修复这些差距。
循环回到有问题部分的优化。
如果无法访问子代理 ：
用户需要手动执行测试。
询问人们在尝试发现此文档时可能会问什么问题。他们会向 Opencode 输入什么？
生成 5-10 个读者会实际提出的问题。
提供测试说明：
对于每个问题，指示读者 Opencode 提供：
检查读者 Opencode 是否给出正确答案或误解任何内容。
还询问读者 Opencode：
询问读者 Opencode 答错或遇到困难的内容。表明打算修复这些差距。
循环回到任何有问题部分的优化。
当读者 Opencode 始终正确回答问题且未发现新的差距或歧义时，文档就准备好了。
当读者测试通过时： 宣布文档已通过读者 Opencode 测试。在完成之前：
询问他们是否想要最后一次审查，或者工作是否完成。
如果用户想要最终审查，提供它。否则： 宣布文档完成。提供一些最终提示：
语气：
处理偏差：
上下文管理：
Artifact 管理：
质量优于速度：