文档引导
这是一次性的批量任务。在此之后进行更改时，请使用 engineering:documentation-sync。
1. 盘点
列出已有的文档，并将每个文档标记为存在、薄弱（存在但大部分为空或过时）或缺失。至少检查以下文档：
README.md、CONTRIBUTING.md、CHANGELOG.md、ARCHITECTURE.md 或 docs/architecture/、决策记录、CLAUDE.md、SECURITY.md、LICENSE、API 参考文档、配置参考文档、操作手册。
git ls-files '*.md' | grep -v node_modules
2. 让用户选择
显示来自 resources/doc-catalog.md 的菜单。将每种文档类型标记为存在、薄弱或缺失。标记你为这类项目推荐的类型。
- 已存在的文档不会被重写。用户可以选择“修订”一个薄弱的文档。
- 用户进行选择。不要编写用户未选择的文档类型。
3. 构建事实表
在任何人编写之前，收集多个文档都会用到的事实。这些事实来自代码和 Git，而不是来自记忆。将它们写入一个临时文件。
| 事实 | 来源 |
|---|---|
| 项目名称和一句话用途 | README、manifest、用户 |
| 当前版本 | manifest、最新标签 (git describe --tags --abbrev=0) |
| 语言、框架及其版本 | manifest 和 lock 文件 |
| 安装、测试、lint、构建和运行命令 | engineering:development-commands |
| 组件及其名称 | 目录结构、入口点、compose 文件 |
| 环境变量和设置 | .env.example 以及读取设置的代码（搜索 process.env、os.environ、getenv） |
| 重要日期 | 第一次提交 (git log --reverse)、标签 |
| 当前能正常工作的情况和不能正常工作的情况 | 用户、开放的 issue |
如果两个来源不一致，请询问用户。不要默默地选择其中一个。每个编写者只使用事实表和代码。
4. 编写
- 三个文档或更少： 自行逐个编写。
- 超过三个： 为每个文档或小组启动一个子代理，一次最多启动四个。为每个子代理提供：
- 它负责的确切文件，以及它不得更改任何其他文件的规则；
- 事实表；
- 来自
resources/doc-catalog.md的其类型的章节大纲； - 使用简化技术英语编写的指示（如果已安装
simple-english技能）； - 如果需要但未找到事实，则报告而非编造的指示。
不要编造历史、数字、用户或功能。编写“TBD”并将其列出给用户。
5. 检查集合
遵循 resources/consistency-check.md。在继续之前修复所有问题。
6. 提交
将文档放入一个分支（engineering:git-branching）并创建一个 PR（engineering:github-pr-merge）。在 PR 正文中，列出每个新文档以及需要用户回答的每个“TBD”。
相关技能
engineering:documentation-sync：在此之后保持这些文档的正确性。gener8v:brownfield：将现有代码库接入 gener8v 流水线。它编写.gener8v/上下文，而非这些项目文档。