用途：检测文档漂移（documentation drift）并通过 PR 修复，不做重写、不制造无谓改动。
适用时机：定期文档复查（如每周或发布后）、重大功能合并后、被问“文档是否最新”、被要求审计 README / SPEC / PRODUCT 准确性。
目标文档：README.md（功能表、路线图、快速开始、“是什么”描述、“works with”表）；doc/SPEC.md（避免错误的“不支持”声明，主要模型/模式准确性）；doc/PRODUCT.md（核心概念、功能列表、原则准确性）。不在范围内：DEVELOPING.md、DATABASE.md、CLI.md、doc/plans/、技能文件、发布说明。
工作流：1）检测变更，读取上次复查游标 .doc-review-cursor，首次运行回看 60 天，用 git log "$LAST_SHA"..HEAD --oneline --no-merges 收集提交；2）分类变更，分为 Feature、Breaking、Structural，忽略重构、仅测试、CI、依赖升级、仅文档、格式类提交，边界情况查看实际 diff；3）生成变更摘要；4）逐份审计目标文档，检查漏报（已发布功能未提及）、误报（已发布却仍写 coming soon / roadmap / planned / not supported / TBD）、快速开始准确性、功能表准确性、works-with 准确性，可参考 references/audit-checklist.md 与 references/section-map.md；5）创建分支 docs/maintenance-$(date +%Y%m%d)，只做最小补丁，保留原有语气风格，不做外观改动，不新增章节，路线图项已发布则移出并简短提及；6）提交并开 PR，使用 gh pr create 附变更摘要与复查说明；7）审计成功后用 git rev-parse HEAD > .doc-review-cursor 更新游标。
补丁风格：只改事实不改文风；删除路线图条目时干净移除；新增功能提及需匹配周围格式（如表格则加行）；README 改动尤其要少；SPEC/PRODUCT 优先更新既有表述而非新增章节。
输出报告：扫描提交数、发现的重要变更数、文档编辑数及涉及文件、PR 链接（若有编辑）、需要更大文档工作的后续事项。
限制：仅依据资料所述流程，未提供具体安装命令、收费或平台信息。