用途：为项目在 docs/ 下建立并维护结构统一、轻量的文档，或在代码变化后把已有文档与当前代码库同步。
主要输出：docs/SUMMARY.md 作为文档入口并始终重新生成；docs/architecture/ 记录系统设计、基础设施、组件交互、数据流与功能流；docs/codebase/ 记录文件组织、目录结构、入口点、关键模块及职责；docs/code-standard/ 记录编码约定、命名规则、风格指南、环境搭建及团队自定义规则与模式；docs/project-pdr/ 记录产品目标、用例、业务规则、约束与决策依据。同时保持 README.md 与当前文档链接和项目摘要一致。
工作流程：先做上下文扫描，读取已有文档、README.md 与关键配置（如 package.json、tsconfig.json、Cargo.toml），扫描源码目录，更新时可用 git log --oneline -20 查看近期变更；只依据代码中可确认的事实，不虚构需求或业务逻辑。随后判断是需要初始化还是增量更新，并简要说明。产出文档时，缺失或不完整则创建 docs/ 及四个主题文件夹，每个文件夹至少 1 个按内容命名的文件，文件名不得用 overview.md、index.md、main.md 等通用名，内容覆盖 2 个以上明显不同子主题时应拆分；SUMMARY.md 需严格遵循 references/summary-template.md 模板。若已有标准结构，则进行外科式增量更新：保留有用内容与章节结构，就地修正过时或错误部分，补充新发现的特性、组件或约定，删除明显过时内容，按需增删文件，重新生成 SUMMARY.md 且只列磁盘上实际存在的文件。最后同步 README.md，并做质量校验。
校验要点：SUMMARY.md 存在且列出所有实际文件、无幽灵条目；每个主题文件夹至少 1 个内容文件；无通用文件名；README.md 链接指向 docs/SUMMARY.md；术语一致；文档与代码无矛盾；路径与组件名准确；内容简洁具体可操作。
边界情况：极小或空项目保持简短真实，无内容时标注 TBD，不靠填充凑长度；docs/ 中用户自建文件保留，不移动或重命名，列在 SUMMARY.md 的 Other 下；单体仓库在多包应用中记录整体结构并说明各包用途，不必为每包建完整文档集。
规则与限制：文档保持事实性，不虚构需求；倾向简洁更新而非冗长描述；与当前实现保持一致；不确定时显式标注假设并请求确认；对业务目标、模块归属、约定冲突、架构决策等信息无法可靠推断时，提出针对性问题。