メニュー
引导用户通过结构化的工作流协作编写文档。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流帮助用户高效地传递上下文、通过迭代优化内容,并验证文档是否适合读者阅读。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/evanfang0054/cc-system-creator-scripts --skill doc-coauthoringコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Mac 系统深度清理和优化工具。使用 Mole (mo 命令) 执行系统清理、磁盘分析、应用卸载、系统优化等任务。 触发场景（当用户提到以下任一内容时使用此 skill）： - 清理 Mac、清理磁盘、释放空间、清理缓存、清理系统 - 卸载应用、删除应用、移除应用及其残留 - 磁盘分析、查看磁盘占用、大文件查找、空间分析 - 系统优化、系统维护、刷新系统、重建缓存 - 系统状态、系统监控、CPU/内存/磁盘监控 - 清理 node_modules、清理构建产物、清理项目依赖 - 清理安装包、删除 dmg/pkg 文件 - Mac 清理工具、类似 CleanMyMac 的功能 - "我的 Mac 太慢了"、"磁盘空间不足"、"电脑卡顿" - 即使没有明确说 "Mole"，只要涉及上述场景就应使用
构建 CLI / command-line 工具时使用，支持两种模式。模式 A 人类 CLI（终端 UX、彩色、交互式提示、进度条、Shell 自动补全），关键词包括 commander / yargs / oclif / typer / click / cobra。模式 B agent-native CLI（JSON envelope / schema 自省 / dry-run 写入安全 / 契约驱动），关键词包括 agent-native CLI、JSON envelope、friction signal。混合场景默认走 B（agent 约束更严格）。只要用户提到 CLI、command-line、命令行工具、agent-native、envelope、schema、friction signal，或要给 agent 提供可调用的 CLI 工具，就应主动使用此 skill。
快速搭建和配置 pnpm monorepo 项目结构，包含 TypeScript、tsup 构建、私有 npm registry 配置。当用户需要"创建 monorepo"、"初始化 monorepo 项目"、"配置 pnpm workspace"、"设置 monorepo 构建"、"monorepo setup"时使用。特别适合需要统一管理多个包、配置构建工具、处理 TypeScript 路径问题的场景。即使用户只是说"帮我搭建项目结构"或"配置构建"，如果涉及多包管理也应该使用此 skill。
SKILL.md を表示中
SOC 職業分類に基づく
| name | doc-coauthoring |
| description | 引导用户通过结构化的工作流协作编写文档。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流帮助用户高效地传递上下文、通过迭代优化内容,并验证文档是否适合读者阅读。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。 |
此技能提供了一个结构化的工作流,用于引导用户进行协作式文档创建。作为主动的引导者,带领用户完成三个阶段:上下文收集、优化与结构、读者测试。
触发条件:
初始提议: 为用户提供协作编写文档的结构化工作流。解释三个阶段:
解释这种方法有助于确保文档在被他人阅读时效果良好(包括当他们将其粘贴到 Claude 中时)。询问他们是否想尝试此工作流,还是更喜欢自由形式的工作。
如果用户拒绝,则自由形式工作。如果用户接受,继续第一阶段。
**目标:**缩小用户所知与 Claude 所知之间的差距,以便后续提供智能指导。
首先向用户询问关于文档的元上下文:
告知他们可以用简写方式回答,或以任何最有效的方式倾倒信息。
如果用户提供模板或提到文档类型:
如果用户提到编辑现有共享文档:
一旦初始问题得到回答,鼓励用户倾倒他们拥有的所有上下文。请求以下信息:
建议他们不用担心组织结构——只需把所有信息都倾倒出来。提供多种提供上下文的方式:
如果集成可用(例如:Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器),提及可以使用这些来直接拉取上下文。
如果未检测到集成且在 Claude.ai 或 Claude 应用中: 建议他们可以在 Claude 设置中启用连接器,以允许直接从消息应用和文档存储中拉取上下文。
告知他们在完成初始倾倒后将提出澄清问题。
在上下文收集期间:
如果用户提到团队频道或共享文档:
如果用户提到未知的实体/项目:
当用户提供上下文时,追踪正在学习的内容以及仍不清楚的内容
提出澄清问题:
当用户表示已完成初始倾倒(或提供了大量上下文)后,提出澄清问题以确保理解:
根据上下文中的差距生成 5-10 个编号的问题。
告知他们可以使用简写方式回答(例如:"1: 是,2: 见 #channel,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 进行所有编辑质量优于速度: