draft-openspec-docs

起草 OpenSpec 文档（scratch-plan 工作流）

你要在用户参与下编写文档页面。页面会在自身内容中规划和审阅，然后逐节起草。在起草前，先加载 write-openspec-docs（样式规范）和 no-ai-slop。

1. 设置 scratch 部分

将页面精简为标题和 > 目标行，然后在其下方添加工作部分：

## Scratch: page plan (delete before publish)

### Purpose

### Structure

• 用途：列出 3-5 个要点。说明读者是谁、他们来查找什么、页面涵盖什么内容，以及页面会链接到哪些内容。撰写前，查看 docs-lab/README.md（页面的目标行）和 docs-lab/message-map.md（此页面负责回答的问题）。
• 结构：用编号列表列出页面各部分，每部分一行，说明其内容形式（表格、代码围栏、树形结构、项目符号）。
• 说明页面会做什么，绝不说明页面不会做什么。用词直白、项目简短；用户会在编辑器中阅读这些内容。

2. 反复迭代，直到计划获批

• 修改计划成本低，修改页面成本高。按用户要求反复调整计划，再开始起草。
• 将每项决定都记在计划中，而不只是记在聊天里。添加 ### Notes 列表，记录后续应由其他页面处理的事项，以及过程中发现的产品观察。
• 用户可能会在两轮交流之间直接编辑文件；他们的修改是决定，不是需要还原的偏差。
• 一次只提出一个待决定事项，并给出建议。

3. 添加草稿计划，然后逐步起草

结构确定后，在 Notes 下方添加 ### Draft plan：每个页面部分列为一个步骤，每步都有 ID 和易读的标题（**D1. 目标行和简介**），最后以跨页面更新的整合步骤和清理步骤收尾。然后：

• 等待用户指定步骤 ID。只起草该步骤，并将内容写在页面的 scratch 块上方。
• 写入前，依据来源核实每项事实；快速 grep 胜过盲目信任。参考内容应逐字呈现原始约定（模板、指令、配置），放在代码围栏中，并链接到 GitHub 上的文件，而不是改写概述。
• 让同级部分遵循可重复的子结构，使整个页面读起来像一个统一的体系。
• 在计划中将步骤标记为 (done)，报告已完成的内容，并指出下一步。

4. 整合和清理

• 整合：更新所有指向该页面的内容。包括 README 目标行（必须与页面的 > 行完全一致）、消息映射、同步配置（website/docs.sync.config.mjs），以及通过 grep 整个目录树找到的所有交叉链接。运行 node website/scripts/sync-docs.mjs 进行验证。
• 清理：删除 scratch 块，在桌面和窄屏宽度下运行 write-openspec-docs 中的可检索性测试和快速浏览测试；如果页面文案已写入，则将消息映射中的对应行改为 Answered。