在用户参与下从零起草或重写文档页面时…

当需要与用户协作从零重写一个文档页面或塑造新页面时，在页面内建立临时计划、逐步评审并分节起草。

适用场景

解决思路

1. 起草前先加载 write-openspec-docs（风格权威）和 no-ai-slop 两个技能。
2. 把页面精简到只剩标题和 `>` 目标行，然后在下方添加工作区：`## Scratch: page plan (delete before publish)`，其下含 `### Purpose` 和 `### Structure`。
3. Purpose 写 3-5 个点：读者是谁、他们来查什么、页面覆盖什么、链接到哪些外部内容；写之前先查 docs-lab/README.md（页面的目标行）和 docs-lab/message-map.md（路由到此页的问题）。
4. Structure 写一个编号列表，每行一个章节，命名该章节并说明其内容形态（表格、代码块、树、项目符号）。
5. 只说明页面会做什么，绝不说它不会做什么；用平实词语和短项目符号，因为用户会在编辑器里阅读。
6. 在起草前按用户要求反复重塑计划——计划编辑成本低，页面编辑成本高。
7. 把每个决定记录在计划本身中，而不只是聊天里；添加 `### Notes` 列表记录属于其他页面的后续事项和过程中发现的产品观察。
8. 用户可能在轮次之间直接编辑文件；他们的编辑是决定，不是要回退的漂移。
9. 一次只抛出一个待定项，并附上推荐意见。
10. 结构稳定后，在 notes 下方添加 `### Draft plan`：每个页面章节一个步骤，各有 ID 和可读标题（如 `**D1. Goal line and intro**`），最后以整合步骤（跨页面更新）和清理步骤收尾。
11. 等待用户指定某个步骤 ID，然后只起草该步骤，写入 scratch 块上方的页面中。
12. 写每个事实前先对照来源核实；一次廉价的 grep 胜过信任；参考内容要在代码块中逐字展示原始契约（模板、指令、配置），并链接到 GitHub 上的文件，而不是转述。
13. 让同级章节保持可重复的子结构，使页面读起来像一个系统。
14. 在计划中把该步骤标记为 `(done)`，报告落地内容，并指出下一步。
15. 整合：更新所有指向该页面的内容——README 目标行（与页面的 `>` 行逐字匹配）、message map、同步配置（`website/docs.sync.config.mjs`），以及通过 grep 整棵树找到的交叉链接；运行 `node website/scripts/sync-docs.mjs` 验证。
16. 清理：删除 scratch 块，在桌面和窄宽度下运行 write-openspec-docs 中的可检索性和扫视测试，如果页面正文已落地，就把 message-map 中该行翻转为 Answered。

适用边界 · 注意事项

• 页面只需小幅修改或局部编辑，而非从零重写或塑造新页面时。
• 无法与用户进行多轮交互评审、只能一次性产出时。