菜单
当用户要求协作文档、起草 proposal、编写 technical spec、创建 decision doc 或 RFC，或希望通过迭代合作来组织一份较大文档时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user asks to generate or refresh an architecture map, structure diagram, core call flow, local viewer assets, or runs ~map. Produces hello-scholar native architecture-map.json plus compact Markdown and Mermaid companion artifacts.
Use when the user asks to open the architecture viewer, view diagrams, inspect node evidence, export the local architecture map, or troubleshoot hello-scholar map view/export behavior.
实验分析命令，基于 experiment package、runs、metrics 和 evidence 形成结果解释与下一轮实验计划。
实现命令，把 plan package、change record 或 experiment package 落成代码、配置、文档或实验变更。
Use only when the user explicitly types ~map. Generates or refreshes the hello-scholar native architecture map by invoking the architecture-map workflow, then validates and points to the local viewer.
用于涉及编写或修改源码的日常编码任务。
| name | doc-coauthoring |
| description | 当用户要求协作文档、起草 proposal、编写 technical spec、创建 decision doc 或 RFC，或希望通过迭代合作来组织一份较大文档时使用。 |
| version | 0.1.0 |
本 skill 提供一套结构化协作文档工作流。作为主动引导者，带用户经历三个阶段：Context Gathering、Refinement & Structure、Reader Testing。
在提出 connector、artifact 或 reader-test subagent 方案前，先阅读 references/RUNTIME-MATRIX.md，判断当前环境真正可用的能力。
如果没有 artifact 这一类工作面，默认回退到用户指定路径中的普通 Markdown 文件，或一个明确命名的工作文件。不要假定 artifact 一定可用。
触发条件：
初始引导： 向用户提供这套结构化协作流程，并简要说明三个阶段：
说明这种方式的目标是让文档对“真正的读者”也同样有效，包括把文档贴进 Claude 的读者。再询问用户要不要采用这套流程，还是自由写作。
如果用户拒绝，就用 freeform 方式工作；如果接受，就进入 Stage 1。
Before drafting, identify the audience, purpose, and what the reader should be able to do after reading. Prefer conclusion-first structure, one core idea per paragraph, clear heading hierarchy, and concrete claims over vague phrasing.
Use active voice where possible. Keep sentences short enough to parse, explain technical terms on first use, label code fences with languages, and preserve necessary caveats, constraints, and risks instead of over-compressing them away.
Delivery checklist:
目标： 缩小“用户知道什么”和“Claude 知道什么”之间的差距，为后续高质量引导建立上下文。
先询问文档的 meta-context：
告诉用户可以简答，也可以直接把信息整段倒出来。
如果用户提供模板或提到文档类型：
如果用户说要修改已有共享文档：
初始问题回答后，鼓励用户把上下文一次性倾倒出来。重点信息包括：
告诉用户不必提前整理结构，先把材料倒出来即可。支持多种提供方式：
如果有可用集成（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP server），可以说明这些内容可直接拉取。
如果没有集成，且位于 Claude.ai / Claude app： 建议用户在 Claude 设置里启用 connector，以便直接拉取聊天记录和文档存储内容。
告诉用户，在完成首轮信息倾倒后会继续追问澄清问题。
在收集上下文时：
如果用户提到团队频道或共享文档：
如果用户提到未知的实体 / 项目：
随着上下文逐步输入，持续跟踪：已经明确了什么、仍然模糊什么
如何追问：
当用户表示首轮信息已经给完，或上下文已经比较充分时，基于现有空白提出 5-10 个编号澄清问题。
告诉用户可以用非常简短的方式回答，例如：
1: yes2: see #channel3: no because backwards compat也可以继续给文档链接、频道路径，或者继续信息倾倒，以最高效率为准。
退出条件： 当已经能直接讨论 edge case 和 trade-off，而不再需要补基础背景时，说明上下文已足够。
阶段切换： 询问用户此阶段是否还有要补充的背景，还是可以进入文档起草。
如果用户还想继续补充，就继续；准备好后进入 Stage 2。
目标： 通过头脑风暴、筛选和迭代精修，按章节逐步写出文档。
对用户的说明： 文档会按 section 逐块构建。每个 section 的流程：
优先从未知数最多的部分开始。对 decision doc，通常是核心 proposal；对 spec，通常是 technical approach。summary 一类内容适合最后写。
如果文档结构已经明确：
如果用户还不知道需要哪些 section：
一旦结构达成一致：
先创建带占位符的初始文档结构。
如果 artifact 可用：
create_file 创建 artifact，作为双方共同工作的骨架如果 artifact 不可用：
decision-doc.md、technical-spec.md宣布开始处理 [SECTION NAME]，围绕这一节应包含的内容提出 5-10 个具体问题。
告诉用户可以简答，也可以只指出哪些点最重要。
针对 [SECTION NAME] 头脑风暴 5-20 个可纳入内容，复杂度越高，选项数越多。重点寻找：
给出编号列表，并在末尾说明：如果需要，还可以继续扩展更多选项。
让用户指出哪些点应该保留、删除或合并，并尽量给出简短原因，方便后续章节学习他们的偏好。
示例：
Keep 1,4,7,9Remove 3 (duplicates 1)Remove 6 (audience already knows this)Combine 11 and 12如果用户给的是自由反馈，而不是编号选择，也要主动提取他们的偏好并继续推进。
根据已选内容，追问这一节是否还有重要遗漏。
使用 str_replace 把这一节的占位符替换为正式草稿。
告知用户：将根据刚才选定的内容起草 [SECTION NAME]。
如果使用 artifact：
如果使用普通文件：
[filename]在第一次起草时要额外提醒： 尽量不要直接改文档，而是描述想怎么改，这样更容易学习他们的风格，例如：
用户给反馈后：
str_replace 直接编辑，不要整篇重打持续迭代，直到用户满意。
如果连续 3 轮都没有实质修改，询问是否还有内容可以删掉而不损失信息。
当某一节完成后，确认 [SECTION NAME] 已完成，再问是否进入下一节。
对所有 section 重复这一流程。
当文档完成度超过 80% 时，主动重读整篇文档，并检查：
读完整篇后给出反馈。
当所有章节都已完成： 说明整篇文档已写完，并将再做一次整体审阅，检查 coherence、flow 和 completeness。
给出最终建议后，询问用户是进入 Reader Testing，还是还要继续精修。
目标： 用一个没有上下文污染的全新 Claude 验证文档对真实读者是否有效。
对用户的说明： Reader Testing 的目的是发现作者视角看不出来的盲点，也就是“作者觉得理所当然，但读者并不懂”的地方。
如果可用 sub-agent（例如 Claude Code 场景）：
直接执行测试，无需用户手工参与。
宣布将先预测真实读者在发现这份文档时会问什么。
给出 5-10 个真实问题。
说明将用一个“没有本对话上下文”的全新 Claude 实例来测试这些问题。
对每个问题，都调用 sub-agent，仅传入文档内容和该问题。
总结 Reader Claude 在每个问题上答对了什么、答错了什么。
继续调用 sub-agent 检查：
汇总发现的问题。
如果发现问题：
如果没有 sub-agent（如 claude.ai web 界面）：
让用户手动完成测试。
询问：别人如果在 Claude.ai 中尝试理解这份文档，会问什么问题？
据此生成 5-10 个读者问题。
给出操作说明：
https://claude.ai每个问题都要求 Reader Claude 返回：
检查 Reader Claude 是否答对，或者是否出现误解。
还要额外问 Reader Claude：
询问 Reader Claude 卡住了什么，或答错了什么，然后回到对应章节修补。
当 Reader Claude 能持续正确回答问题，且不再暴露新的 gap 或歧义时，说明文档已经准备好交给真实读者。
当 Reader Testing 通过后：
询问是否还要再做一次 review，还是已经完成。
如果用户还要最终 review，就继续。否则： 宣布文档完成，并给出几点收尾建议：
语气：
偏离处理：
上下文管理：
Artifact 管理：
create_file 起草完整 sectionstr_replace质量优先于速度：
只按需加载：
references/RUNTIME-MATRIX.md - 如何根据 Claude Code、Claude.ai、connector 丰富 / 匮乏环境调整流程references/DOC-TYPES.md - 常见文档类型的默认章节骨架references/READER-TEST.md - reader testing 的提示词、交接包与通过 / 失败信号