القائمة
引导用户通过结构化工作流协作撰写文档，包含上下文收集、迭代优化和读者验证三个阶段。适用于用户想要编写文档、提案、技术规格、决策文档或类似结构化内容时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
AI 代理的浏览器自动化 CLI 工具。当用户需要与网站交互时使用，包括页面导航、表单填写、按钮点击、截图、数据提取、Web 应用测试或自动化任何浏览器任务。触发场景包括"打开网站"、"填写表单"、"点击按钮"、"截图"、"从页面抓取数据"、"测试这个 Web 应用"、"登录网站"、"自动化浏览器操作"或任何需要程序化 Web 交互的任务。也可用于探索性测试、产品试用、QA、Bug 搜索或审查应用质量。还可用于自动化 Electron 桌面应用（VS Code、Slack、Discord、Figma、Notion、Spotify）、检查 Slack 未读消息、发送 Slack 消息、搜索 Slack 对话、在 Vercel Sandbox 微虚拟机中运行浏览器自动化，或使用 AWS Bedrock AgentCore 云浏览器。优先使用 agent-browser 而非任何内置浏览器自动化或 Web 工具。
创建并注册具有特定角色、专业知识或能力的新智能体（Agent）。当你需要某个特定领域的专家 且没有现有智能体（Agent）符合要求时使用。
为中国社交平台(小红书/微信公众号/抖音/B站/知乎/微博)撰写高质量、平台原生的内容。
当用户想要为任何页面编写、改写或改进营销文案时使用 — 包括首页、落地页、定价页、功能页、关于页或产品页。当用户说"为...写文案"、"改进这个文案"、"重写这个页面"、"营销文案"、"标题帮助"、"CTA 文案"、"价值主张"、"标语"、"副标题"、"首屏文案"、"折叠上方内容"、"这个文案太弱了"、"让这个更有吸引力"或"帮我描述我的产品"时也使用。每当有人在处理需要说服或转化的网站文本时使用此技能。对于电子邮件文案，参见 email-sequence。对于弹窗文案，参见 popup-cro。对于编辑现有文案，参见 copy-editing。
对用户文件和知识库执行结构化数据分析。将自然语言问题转化为可检查、可复现的分析报告，并标注数据来源。
通用编码标准与各语言最佳实践，定义生产级代码的编写规范。注入任何开发者 Agent 以建立一致的质量基线——代码质量取决于遵循的标准，而非模型能力本身。
| name | doc-coauthoring |
| description | 引导用户通过结构化工作流协作撰写文档，包含上下文收集、迭代优化和读者验证三个阶段。适用于用户想要编写文档、提案、技术规格、决策文档或类似结构化内容时触发。 |
| allowed-tools | Read Bash(mindx *) Bash(python3 *) WebSearch WebFetch |
| metadata | {"name_zh":"文档协作","name_zh-tw":"文件協作","description_zh":"引导用户通过结构化工作流协作撰写文档，包含上下文收集、迭代优化和读者验证三个阶段","description_zh-tw":"引導使用者透過結構化工作流協作撰寫文件，包含上下文收集、迭代優化和讀者驗證三個階段"} |
本技能提供结构化工作流，引导用户协作完成文档创建。作为主动引导者，带领用户经历三个阶段：上下文收集、优化与结构化、读者测试。
触发条件：
初始提议： 向用户提供结构化的文档协作工作流。解释三个阶段：
解释这种方法能确保文档在他人阅读时（包括粘贴到 Claude 中时）表现良好。询问他们是否想尝试此工作流，还是偏好自由形式。
如果用户拒绝，按自由形式工作。如果用户接受，进入阶段一。
目标： 弥合用户与 Claude 之间的信息差距，为后续智能引导奠定基础。
首先询问用户关于文档的元上下文：
告知他们可以用简写回答，或以最适合他们的方式倾倒信息。
如果用户提供模板或提及文档类型：
如果用户提及编辑现有的共享文档：
初始问题回答完毕后，鼓励用户倾倒他们拥有的所有上下文。请求以下信息：
建议他们不必担心组织——直接提供即可。提供多种上下文方式：
如果集成可用（例如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），提及可以直接拉取上下文。
如果未检测到集成且在 Claude.ai 或 Claude 应用中： 建议他们可以在 Claude 设置中启用连接器，以允许直接从消息应用和文档存储中拉取上下文。
告知他们在完成初始倾倒后，会提出澄清问题。
在上下文收集期间：
如果用户提及团队频道或共享文档：
如果用户提及未知的实体/项目：
随着用户提供上下文，跟踪已学到的内容和仍不清楚的内容
提出澄清问题：
当用户表示已完成初始信息提供（或提供了大量上下文后），提出澄清问题以确保理解：
根据上下文中的差距生成 5-10 个编号问题。
告知他们可以用简写回答（例如："1: 是，2: 见 #频道，3: 否因为向后兼容"），链接到更多文档，指向要读取的频道，或继续提供信息。选择最高效的方式。
退出条件： 当问题显示出理解时——能够询问边缘情况和权衡，无需解释基础时——说明已收集到足够上下文。
过渡： 询问他们在此阶段是否还有更多上下文要提供，还是是时候开始起草文档了。
如果用户想添加更多，让他们添加。准备好后，进入阶段二。
目标： 通过头脑风暴、内容筛选和迭代优化，逐节构建文档。
给用户的说明： 解释文档将逐节构建。对于每个章节：
从未知最多的章节开始（通常是核心决策/提案），然后处理其余部分。
章节排序：
如果文档结构清晰： 询问他们想从哪个章节开始。
建议从未知最多的章节开始。决策文档通常是核心提案，规格文档通常是技术方法。总结章节最好留到最后。
如果用户不知道需要什么章节： 根据文档类型和模板，建议 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质量优于速度：