القائمة
引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
يُحدَّد 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.
عرض 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 管理：
质量优于速度：
استنادا إلى تصنيف SOC المهني