文档协作助手

写文档时常见的问题

技术文档、PRD、设计说明或决策记录往往卡在两件事上：作者脑子里有大量未写出的上下文，而读者（或把文档贴进 Claude 的同事）只能看到成稿。结果是章节结构拍脑袋、关键权衡没写出来、术语和前提被默认「大家都懂」。本技能把协作写文档拆成可重复的三段流程，让模型从「代写」变成带节奏的共著向导。

技能如何工作

触发时机：当你提到写文档、起草提案、做 spec，或明确文档类型（如 PRD、RFC、design doc）时，技能会先说明三阶段流程，由你选择结构化协作或自由发挥。

1. Context Gathering（上下文收集）：先问文档类型、受众、期望影响、模板与约束；鼓励你把背景、讨论串、架构与组织语境一次性「倒出来」。有 Slack / Drive 等集成时可拉取材料；缺 alt 的配图会提醒补描述。收集到位后，用 5～10 个澄清问题补齐盲区。
2. Refinement & Structure（打磨与结构）：按章节推进——每节先澄清、再头脑风暴 5～20 条候选项、你勾选保留/合并/删除后成稿，并用 str_replace 做外科手术式修改而非整篇重写。通常从最不确定的核心章节（决策/技术方案）开始，摘要类章节放最后；接近完成时会通读查冗余、矛盾与空话。
3. Reader Testing（读者测试）：用无本对话上下文的新 Claude 实例，模拟读者提问与歧义检查，找出「作者懂、读者懵」的漏洞，再回到对应章节修订。

成稿可落在 artifact 或工作区 Markdown 文件（如 decision-doc.md），并约定你通过「指出改什么」来迭代，以便后续章节对齐你的表述习惯。

适用边界

• 面向 substantial 写作任务；若你拒绝结构化流程，技能会退回自由模式。
• Reader Testing 在支持 sub-agent 的环境（如 Claude Code）里可自动跑；否则需按技能说明手动做读者视角检查。
• 集成与连接器取决于当前客户端是否启用；无集成时需自行粘贴频道或文档内容。