用途：以维护者身份审查进入 docker/docs 的文档 PR，判断内容是否事实正确、是否真正让文档整体更好。技术上正确但位置不当、过度强调、重复或无助于目标读者的补充，仍视为不足。
主要能力：分两阶段工作。第一阶段研究 PR、给出结论并展示拟发布的评论原文；第二阶段等待用户明确确认后，只发布已确认的文字。确认前不得发布评论、提交 GitHub review、批准或请求修改、解决讨论串、推送提交、修改标签或对 GitHub 做任何变更。请求审查或起草反馈不等于确认发布，需询问“Post these comments?”并停止。
使用方式：先收集完整上下文，检查 PR 元数据、正文、提交、变更文件、检查、对话、评审和关联 issue；内联评论需单独获取，因为 gh pr view --json reviews 会遗漏它们。命令示例：gh pr view <PR> --repo docker/docs --json number,title,url,state,author,body,baseRefName,headRefName,headRefOid,commits,files,comments,reviews,reviewDecision,statusCheckRollup；gh api repos/docker/docs/pulls/<PR>/comments --jq '[.[] | {id, author: .user.login, body, path, line, side, commit_id}]'；gh pr diff <PR> --repo docker/docs。随后独立核实每个实质说法，对照产品源码、上游文档、规范、发布说明或安全的本地复现，并阅读 STYLE.md、COMPONENTS.md 及相关仓库说明，判断文件是否为生成或上游维护。
编辑评估：判断该补充是否改变读者在本页的决策或下一步、是否属于该概念的规范页面、是否已在别处记录、是否用简短指引加链接比重复解释更好、视觉与文字权重是否与价值相称。优先在规范位置保留一处连贯解释。
结论类型：Approve、Approve with optional polish、Focused rewrite、Close / no docs change，并附证据；措辞问题应给出确切替换文本。反馈放置：窄范围行级问题用内联评论，范围、信息架构、整体方案用 PR 级评论，必要时两者并用但不重复。发布前重新获取 head SHA 与 diff，若变化则停止并重新确认。内联评论尽量以单次 comment-only review 发布：gh api repos/docker/docs/pulls/<PR>/reviews --method POST --input <payload>；整体反馈用 gh pr comment <PR> --repo docker/docs --body-file <file>。使用 APPROVE 或 REQUEST_CHANGES 需单独明确授权。
限制：外部说法或替换 URL 无法核实时应报告该限制而非猜测；不得猜测行号；GitHub 拒绝内联位置时不得静默改为 PR 级评论；发布后需核验并报告 URL 与位置。其他平台、收费与价格信息暂未提供。