用途 docs-verifier 用于核验文档页面上所有可检查的陈述在当前代码中是否为真，并生成逐条声明（claim-by-claim）报告，为每项判断标注支撑它的 file:line。它与 docs-reviewer（文风）和 docs-audit（页面是否需要改进）不同，只检查真实性，且检查全部内容。页面与代码不一致时，页面即错误，不得修改源码去匹配页面。
核验范围与真相来源 只核验被指定的页面，通常一到两页：site/src/content/docs/ 下的页面路径或其 URL；某个文档 PR 或分支的改动页面；某次代码改动所涉及的页面。未给出目标时应先询问，不得默认核验整站。 各类真相来源：Python SDK 对应 strands-py/src/strands/ 与其模块 all；TypeScript SDK 对应 strands-ts/src/ 与 strands-ts/src/index.ts（@internal 不算公开）；Python harness 对应 harness-py/src/strands_harness/ 与其 init.py；TypeScript harness 对应 harness-ts/src/ 与 index.ts（./internal 不算公开）；CLI 对应 strands-cli/src/，聊天内斜杠命令在 strands-cli/src/tui/chat/commands.ts；MCP server 对应 strands-mcp/src/strands_mcp_server/ 及其注册的 MCP 工具。user-guide/evals-sdk/、user-guide/box/、user-guide/shell/ 不在本仓库内，需浅克隆对应仓库到 .context/src/<repo> 或通过 gh api 读取，并以 <repo>/<path>:line 引用。
流程 Step 1 定位页面：记录 git rev-parse --short HEAD 与分支，读取页面及 frontmatter（languages、experimental、sourceLinks）；解析所有 --8<-- "path:region" 引入块并确认区域有匹配的起止标记。Step 2 建立声明清单：在核验前编号列出每条可检查声明及其行号，代码块按语言标签逐项列出导入、调用、参数名与值、属性、输出、安装命令及注释中的断言；正文、表格、提示块中的名称、签名、默认值、数字、行为与顺序、错误类型、语言/提供商支持情况、环境变量、标志和链接也在列；frontmatter 中的 sourceLinks、languages、experimental 同样检查；动机与观点句标为“非声明”。Step 3 对照源码核验：追踪行为而非从名称或注释推断，数字要找到常量及其使用处，各语言分别检查，确认符号公开、生命周期状态，并通过提交历史与标签确认已发布。Step 4 机械检查代码：编译每个代码块并在可行时运行，TypeScript 片段按 CI 顺序安装并类型检查，再单独检查渲染块；Python 用 uv 虚拟环境安装并运行，运行到首次模型调用为止。Step 5 检查链接：内部链接与锚点、API 引用、GitHub 路径是否有效。Step 6 评估：准确度分为 correct、incorrect、incomplete、unverifiable；影响分为 high、medium、low；检查方式记录为 read、compiled 或 executed；风险标签包括 deprecated、internal、unreleased、one-language、accidental、experimental。Step 7 清理临时文件并检查 git 状态。
输出格式 报告包含文件、核验依据的提交与分支、结果统计、发现表格（行号、声明、准确度、影响、标签、检查方式、证据、建议修复）、完整声明清单与已运行命令表。即使没有发现也需给出完整清单，便于审阅者复核；多页时每页一份报告并附汇总表，保存至 .context/docs-verifier/<page-slug>.md 并在回复中返回。
适用场景与限制 适用于发布前的文档事实核查、文档 PR 评审和代码改动后的文档同步检查。不涵盖文风、结构、术语（属 docs-reviewer、docs-audit）；不编辑源码；报告之后可提出仅改文档的修复建议，经用户同意后再实施；不执行提交、推送与 PR。安装命令与具体调用方式在现有资料中暂未提供。