Auto Doc Index — Derived Indexes from Frontmatter
Replaces hand-maintained index tables in README.md with auto-generated
tables derived from structured frontmatter in individual doc files.
Why This Matters — Real Evidence
In a real project with 13 ADR files, comparing hand-maintained index vs
auto-generated index revealed 8 discrepancies (62% error rate):
| Issue Type | Example | Count |
|---|
| Title truncated | "activate none" vs actual "activate none by default" | 2 |
| Status fabricated |
Index said "Decided" but file said "Accepted" | 3 |
|
Date invented | Index showed "2026-01-28" but file had no Date field | 1 |
|
Metadata lost | "(revised 2026-01-28)" stripped from status | 1 |
|
Case "normalized" |
decided silently changed to
Decided | 4 |
These aren't hypothetical risks — they were already present and invisible
in a well-maintained project. Hand-editing creates a false sense of
correctness while the index silently diverges from its source files.
When to Use
- - Setting up a new documentation directory (ADR, RFC, Pitfall, Design Doc, etc.)
- Adding a new document to an existing indexed directory
- Onboarding a project that has hand-maintained doc indexes showing signs of drift
- Resolving recurring merge conflicts in shared
README.md index tables - Migrating from hand-maintained indexes to auto-generated ones
Boundaries
- - This skill generates index tables only — it does not create or modify the content of individual documents.
- The generator script replaces content only between
<!-- INDEX:START --> and <!-- INDEX:END --> markers. All other README.md content is preserved verbatim. - Do NOT use this for indexes that require editorial curation (e.g., "recommended reading order"). Auto-generation is for factual, exhaustive catalogs.
- Do NOT introduce YAML frontmatter parsing libraries — the regex-based approach is intentional to keep the script zero-dependency.
- This skill targets file-system-based documentation. It does not apply to wiki-style or database-backed doc systems.
Problem
A hand-maintained index in README.md is shared mutable state — every
new document requires editing the same file, same table, often the same diff
hunk. In multi-agent or multi-contributor workflows this creates:
- - Silent data loss: titles get shortened, statuses get "corrected"
- Merge conflicts: semantically independent changes collide in the same hunk
- Stale indexes: contributors forget to update, nobody notices
- Normalization illusion: edits look "cleaner" but diverge from source
Solution
Each document is self-describing via frontmatter. A generator script scans
the directory, parses frontmatter, and injects the index table between
<!-- INDEX:START --> / <!-- INDEX:END --> markers in README.md.
Write ops become N:N (each file independent). Index becomes a stateless pure function.
Setup Steps
1. Define frontmatter convention
Choose a frontmatter format for your doc type. Two common patterns:
Pattern A — Inline metadata (ADR/RFC style):
CODEBLOCK0
Pattern B — Bold-field metadata (Pitfall/Postmortem style):
CODEBLOCK1
2. Add markers to README.md
Wrap the existing index table (or create a placeholder) with markers:
CODEBLOCK2
Content outside markers is never touched by the generator.
3. Create the generator script
Copy template/generate-doc-index.ts from this skill's template directory,
or generate a new one following the pattern below.
Core architecture (zero external dependencies):
CODEBLOCK3
See template/generate-doc-index.ts for a
working implementation that handles both Pattern A and Pattern B.
4. Run the generator
CODEBLOCK4
5. Update documentation governance
Add to your project's AGENTS.md or CONTRIBUTING.md:
Rule: Never hand-edit the index table between <!-- INDEX:START/END -->
markers. To add a new document, create the .md file with proper
frontmatter, then run the generator.
Workflow Comparison
CODEBLOCK5
Adding a New Doc Type
To support a new document category (e.g. RFCs, Design Docs):
- 1. Define the frontmatter convention
- Add a parser function (regex for title, status, date, etc.)
- Add a table generator function (column layout)
- Add
<!-- INDEX:START/END --> markers to the README.md - Register in the script's
main() dispatcher
Anti-patterns
- - Do NOT use YAML frontmatter libraries — regex is sufficient and avoids deps.
- Do NOT generate the entire README.md — only the index section. Preserve
manually-written intro, templates, and notes via the marker pattern.
- - Do NOT require contributors to run the generator before committing.
Run it in CI or as a pre-commit hook for enforcement.
Checklist
CODEBLOCK6
技能名称: auto-doc-index
详细描述:
自动文档索引 — 基于前置元数据生成的派生索引
用自动生成的表格替换 README.md 中手动维护的索引表,这些表格源自各个文档文件中的结构化前置元数据。
为何重要 — 真实证据
在一个包含 13 个 ADR 文件的实际项目中,对比手动维护的索引与自动生成的索引,发现了 8 处差异(62% 的错误率):
| 问题类型 | 示例 | 数量 |
|---|
| 标题截断 | activate none 与实际 activate none by default | 2 |
| 状态捏造 |
索引显示已决定但文件显示已接受 | 3 |
|
日期编造 | 索引显示2026-01-28但文件没有日期字段 | 1 |
|
元数据丢失 | 状态中的(修订于 2026-01-28)被剥离 | 1 |
|
大小写规范化 | decided 被静默改为 Decided | 4 |
这些并非假设性风险——它们在一个维护良好的项目中已经存在且不可见。手动编辑造成了一种正确性的假象,而索引却在静默地与源文件产生偏差。
使用场景
- - 建立新的文档目录(ADR、RFC、陷阱、设计文档等)
- 向现有索引目录添加新文档
- 接手一个文档索引出现漂移迹象的项目
- 解决共享 README.md 索引表中反复出现的合并冲突
- 从手动维护的索引迁移到自动生成的索引
边界
- - 此技能仅生成索引表——它不会创建或修改单个文档的内容。
- 生成器脚本仅替换 和 标记之间的内容。所有其他 README.md 内容将原样保留。
- 不要用于需要编辑策划的索引(例如推荐阅读顺序)。自动生成适用于事实性的、详尽的目录。
- 不要引入 YAML 前置元数据解析库——基于正则表达式的方法是有意为之,以保持脚本零依赖。
- 此技能针对基于文件系统的文档。不适用于维基风格或数据库支持的文档系统。
问题
README.md 中手动维护的索引是共享的可变状态——每个新文档都需要编辑同一个文件、同一个表格,通常是同一个差异块。在多智能体或多贡献者工作流中,这会导致:
- - 静默数据丢失:标题被缩短,状态被纠正
- 合并冲突:语义上独立的更改在同一个差异块中碰撞
- 过时索引:贡献者忘记更新,无人察觉
- 规范化错觉:编辑看起来更整洁,但与源文件产生偏差
解决方案
每个文档通过前置元数据进行自描述。生成器脚本扫描目录,解析前置元数据,并将索引表注入到 README.md 中的 / 标记之间。
写入操作变为 N:N(每个文件独立)。索引变为无状态的纯函数。
设置步骤
1. 定义前置元数据约定
为你的文档类型选择一种前置元数据格式。两种常见模式:
模式 A — 内联元数据(ADR/RFC 风格):
markdown
ADR-001: 标题在此
状态: 已决定
日期: 2026-01-28
上下文
...
模式 B — 粗体字段元数据(陷阱/事后分析风格):
markdown
PIT-001: 标题在此
日期: 2026-01-28
领域: 引擎
严重性: 高
状态: 已解决
2. 向 README.md 添加标记
用标记包裹现有的索引表(或创建一个占位符):
markdown
索引
| ADR | 标题 | 状态 | 日期 |
|-----|-------|--------|------|
其他部分(保留)
...
标记之外的内容永远不会被生成器触碰。
3. 创建生成器脚本
从本技能的模板目录复制 template/generate-doc-index.ts,或按照以下模式生成一个新的。
核心架构(零外部依赖):
typescript
// 1. 扫描目录以查找匹配的文件(例如 /^\d{3}-.*\.md$/)
// 2. 从每个文件中解析前置元数据(基于正则表达式,无需 YAML 库)
// 3. 按 ID/编号排序条目
// 4. 生成 Markdown 表格字符串
// 5. 注入到 和 标记之间
参见 template/generate-doc-index.ts 获取能处理模式 A 和模式 B 的工作实现。
4. 运行生成器
bash
npx tsx scripts/generate-doc-index.ts all
5. 更新文档治理规范
添加到项目的 AGENTS.md 或 CONTRIBUTING.md:
规则:切勿手动编辑 标记之间的索引表。要添加新文档,请创建带有正确前置元数据的 .md 文件,然后运行生成器。
工作流对比
旧方式:编写文档 → 手动编辑 README.md 索引 → 冲突风险
新方式:编写文档 → 运行生成器 → 幂等重建,零冲突
添加新文档类型
要支持新的文档类别(例如 RFC、设计文档):
- 1. 定义前置元数据约定
- 添加解析函数(用于标题、状态、日期等的正则表达式)
- 添加表格生成函数(列布局)
- 向 README.md 添加 标记
- 在脚本的 main() 调度器中注册
反模式
- - 不要使用 YAML 前置元数据库——正则表达式已足够且避免了依赖。
- 不要生成整个 README.md——只生成索引部分。通过标记模式保留手动编写的介绍、模板和注释。
- 不要要求贡献者在提交前运行生成器。在 CI 中或作为预提交钩子运行以强制执行。
检查清单
- - [ ] 为每种文档类型定义前置元数据约定
- [ ] README.md 包含 和 标记
- [ ] 生成器脚本已创建并测试
- [ ] 文档治理规范已更新(AGENTS.md / CONTRIBUTING.md)
- [ ] (可选)已添加预提交钩子或 CI 步骤