用途：在变更完成或宣布可发布前，判断该变更对文档的影响，并让文档与用户实际使用的行为保持一致。先检查实际变更及其调用方，再决定哪些文档需要处理；得出“无需修改”且有依据的结论也是完整结果。
模式与范围：任务授权更新文档时用 author 模式；审计、独立审查、状态询问等只读任务用 review 模式，遵循调用方指定的模式，授权不明时先以 review 模式检查并报告。author 模式只在授权变更范围内更新受影响的文档，不动无关内容；review 模式只检查不编辑所评判的产物，把发现交给作者，不自行修复并自我认证。委派、模型选择、续跑和人工关卡由调用方工作流负责，本技能不另起协调者或发布流程，也不要求新的规格、工单或文档树。
范围绑定：已提交的工作要解析并记录固定的 base 与 head，检查两者间 diff 及相应版本的实现与文档；本地工作还要检查已暂存、未暂存和相关未跟踪文件，记录内容指纹或保留快照，仅凭干净的 HEAD 或文件名列表不足以识别脏文件内容；非 Git 环境记录明确的实现与文档内容快照。相关输入不可用时须指出缺口，不能声称已覆盖。记录检查过的路径与指纹方法或快照位置，返回结果前复核输入，若并发编辑改变了输入，刷新检查或说明结果已不描述当前产物。
映射读者：阅读仓库说明，找到维护中的文档和示例位置，把变更行为追溯到使用、运行、升级或开发该项目的人。即使没有应用代码变化，公共工作流变更（如技能与配置）也要纳入。按变更影响考虑安装与入门（README、快速上手、教程）、命令/API/标志/默认值/配置/环境变量（CLI 与 API 参考、配置指南、可执行示例）、兼容与升级（迁移升级说明、弃用通知）、发布可见行为（发布说明或变更日志，若仓库维护）、模块边界/数据流/运维行为（架构说明、图表、运行手册、开发者指南）。还要搜索旧名称、旧值和矛盾示例，并在上下文中阅读匹配到的说法；时间戳新、路径匹配、生成文本或渲染图都不能证明事实准确。对每个受影响的读者任务，指出维护中的文档或说明为何无需修改，不要为显得有产出而添加填充文档。
更新或检查：author 模式做满足变更行为的最小修正，遵循仓库文档布局与生成命令，改生成文档的源文件而非手改生成产物，并配合技术写作与去 AI 腔技能；示例要对应真实符号、路径、标志、默认值和支持版本，升级需用户操作时写明操作及新旧行为差异。要跟踪文档所述效果在实现中是否真正发生，接受或报告某设置不等于对应操作会执行；预期与观察行为不一致时按实现问题报告，而不是把缺陷写成受支持行为。review 模式由自己从实现推导受影响的读者任务，对照源码核查作者的覆盖决定，包括“无变化”的说法，把作者回执当作待检查证据而非结论。
是否需要审查：author 结果只有一个——文档已改、公共工作流或文档化契约已改、或文档缺口未解决时，为“需要独立审查”；仅当证据表明纯内部变更无文档影响时，才可“无需独立审查”。公共工作流或文档变更时“无需独立审查”无效。需要独立审查时由另一代理在不编辑产物的情况下审查，结论为通过、需要修改或无法验证；修复后审查者需复查产物再返回通过。只有被检查的变更、文档和相关上下文仍匹配时才能复用结论，rebase 后补丁 ID 相同不能证明文档上下文未变。
验证与返回：在任务授权且安全时运行相关文档检查，并用实际实现对变更示例进行演练，作为完成证据的命令使用 verify-commands 技能；review 模式运行检查时不得修改被审查文件，检查会写输出时用一次性副本。既要检查事实含义，也要检查语法和渲染；默认值写错或图中虚构审批步骤仍算错误。不安全或不可用的检查记为缺口，绝不为了验证示例而部署、发布文档或改动外部数据。返回紧凑结果：模式、范围、检查的修订或快照（含相关本地变更）、受影响的读者任务与文档路径（已做的更新或保持不变的依据）、实际运行的检查及结果、剩余发现或验证缺口；author 模式给出作者结论及证据，review 模式返回通过、需要修改（已确认的遗漏或错误）或无法验证（缺证据无法判断）。作者结论不是独立审查结论。