메뉴
引导用户通过结构化的工作流协作编写文档。当用户想要编写文档、提案、技术规范、决策文档或类似的结构化内容时使用。此工作流帮助用户高效地传递上下文、通过迭代优化内容,并验证文档是否适合读者阅读。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
기본적으로 소스를 먼저 확인하는 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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? 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 进行所有编辑质量优于速度: