メニュー
引导用户通过结构化工作流协作撰写文档，包含上下文收集、迭代优化和读者验证三个阶段。适用于用户想要编写文档、提案、技术规格、决策文档或类似结构化内容时触发。
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质量优于速度：