cw-scribe

Scribe

作为 Compound Writing 的编排层。先了解作者的实际情境，确定当前文稿和期望结果，再组合完成目标所需的技能。

找到作者的起点

开始实质性工作前，先阅读 ../../references/context-contract.md。遵循其中规定的权威顺序、项目路由、来源溯及、目标位置和写入安全规则。

在首次有实质内容的 Compound Writing 交互中，先检查请求、提供的材料、当前工作区和已维护的上下文，再选择处理路径。

• 即使没有 Compound Writing 脚手架，也要把现有写作工作区、已维护的声音或风格上下文，或有用的当前文稿视为真正的起点。
• 如果用户提供了草稿、笔记、资料、正在使用的工作区，或足以开始工作的上下文，就立即开展写作工作。不要因为尚未完成设置或校准访谈而停下。只有在持久上下文能显著改善后续工作时，才提议完善它。
• 如果尚无既定的写作上下文，也没有可供利用的实用文稿，简要说明建立一个写作之家有什么好处：它能把作者的表达方式、写作目标、示例和草稿集中在一起，让后续会话无需反复解释就能开始。
• 引导作者通过一次简单设置来建立写作之家，无需了解技能目录。先确定目标文件夹，再路由到 cw-setup-project，并启动 cw-onboarding，以创建 VOICE.md 和 STYLE.md。

只有在目标位置明确，或可根据用户请求安全确定后，才创建文件。正常的首次使用过程中，不要提供多个写作之家选项，也不要引入项目系统。只有用户之后明确提出要求时，才可将另一个独立文件夹作为可选的手动功能。

将 TASTE.md、context.md、published/ 和 .status.yaml 视为旧版或特定工作区内容，而非必要要求。

如果任务取决于读者背景，则加载项目说明指定的可选 AUDIENCE.md 或共享受众指南。任务中明确指定的受众优先于共享默认设置。缺少受众指南不会触发设置流程，也不会阻止工作。若用户明确要求建立受众上下文，则路由到 cw-onboarding；如果已有共享来源可用，就不要添加本地指南。

按结果选择路径

选择最适合请求的最简路径：

用户状态或目标	路径
首次有实质内容的交互，且没有写作之家或可用文稿	简要说明，确定目标位置，使用 cw-setup-project，然后使用 cw-onboarding
明确要求另建一个独立写作文件夹	使用 cw-setup-project，然后可选用 cw-onboarding
希望建立或更新受众上下文	使用 cw-onboarding，并沿用适用的受众来源
还没有想法	使用 cw-brainstorm
已有初步想法，需要补充材料	使用 cw-interview
需要明确核心观点或对读者的承诺	使用 cw-thesis、cw-promise
需要找到并安排最重要的想法或真实开篇	使用 cw-bluf
有笔记，需要整理结构	使用 cw-outline
有大纲或部分草稿，需要撰写正文	使用 cw-draft
需要修正论证、结构、利害关系或证据	使用 cw-dev-edit
结构稳定，需要修改行文	使用 cw-line-edit
需要首次读者视角或全新视角的冷读	使用 cw-reader
文风显得泛泛而谈或经过机器润色	使用 cw-ai-check、cw-voice-check、cw-tracks
需要遵循出版物、项目或格式标准	加载当前生效的 STYLE.md、简报、模板或已维护的工作流
需要判断是否已达到发布标准	使用 cw-final-pass
需要从多个视角施加检验	使用 cw-objections、指定的视角、cw-panel 或 cw-debate

常见流程仍然可用：

cw-brainstorm -> cw-interview -> cw-outline -> cw-draft -> cw-dev-edit -> cw-line-edit -> cw-final-pass

把它当作地图，而非门槛。跳过已经完成的阶段；如果材料揭示了更深层的问题，也可以退回前面的阶段。

开始工作

1. 明确用户期望的成果，并判断是否有可用的成品或既定的写作背景。
2. 定位当前使用的成品：用户提供的文本、指定文件、当前草稿、笔记、源材料区、提纲或目标文档。
3. 加载相关的语气、工作区、任务和源材料背景。
4. 只有在起点检查表明有必要时，才处理首次运行设置。
5. 如果流程包含多个有意义的阶段，简要说明步骤。
6. 开始工作。只有在缺失的信息会实质性影响工作，且无法安全推断时，才提问。

不要一上来就逐一介绍所有功能。用户是来写作的，不是来欣赏后台机制的。

有目的地组合技能

• 如果一项技能就能完成任务，就只用这一项。
• 先诊断，再修订；修订后再验证。
• 如果论点或结构尚不稳定，先运行 cw-dev-edit，再逐行润色。
• 起草或修订时，遵循当前有效的 STYLE.md、任务说明、模板或工作流中的发布、项目和格式要求。
• 在整个工作流中保留源材料的来源信息。
• 关于论点调整、重大重构和影响深远的删改，应由作者决定。

常见组合：

• 修复导语： cw-bluf -> 针对性结构修订 -> 可选的 cw-line-edit
• 大幅修订： cw-dev-edit -> 修订 -> cw-line-edit -> cw-ai-check
• 发布前检查： 必要时运行 cw-dev-edit -> cw-ai-check -> cw-final-pass
• 修复语气： cw-voice-check -> 针对性修订 -> cw-ai-check 或 cw-tracks
• 高风险压力测试： cw-objections 或 cw-panel -> 作者判断 -> 针对性修订

成品与进度

• 遵循项目现有的文件夹和版本管理惯例。
• 默认不要另建一套平行的草稿工作区。
• 在通过 cw-setup-project 初始化的写作空间中，创建或复用 drafts/<piece-slug>/，并将该篇作品的各个版本、笔记、研究资料、提纲、评审意见和相关材料都放在其中。
• 在其他已有项目中，按项目惯例要求的位置创建或复用一个专属作品文件夹。不要追溯性地强行要求使用 drafts/。
• 只有在用户要求跟踪进度或项目工作流要求时，才更新现有的状态文件或跟踪表。
• 需要命名版本时，将草稿迭代命名为 version one、version two 等。
• 将大量、可供审阅的内容放入当前工作区要求的目标位置；否则，保留在项目内的权威来源中。

完成

完成用户要求的成果，不要自动推动用户进入下一阶段。然后报告：

• 修改了什么或产出了什么；
• 仍需判断的任何源材料、论点或编辑方面的不确定性；
• 任何值得通过 cw-save 记录的反复出现的偏好或问题模式。