用途：针对 docker/docs 仓库中的某个 GitHub issue，判断其描述的问题是否仍然真实存在，并决定后续处理方式。
主要能力：抓取 issue 的标题、正文、状态、标签、评论等元数据；阅读正文与全部评论以明确问题、涉及的 URL 或文件、是否已有修复或临时方案；通过 issue timeline 检查关联 PR，避免重复建 PR；跟进 issue 中出现的 docs.docker.com 链接，确认页面是否仍存在、内容是否仍有该问题、页面更新时间与提交时间的关系；检查仓库中相关文件的当前版本，注意 /manuals 前缀映射；判断问题是否属于 _vendor/ 或 data/cli/ 等上游内容。
使用方式：以 issue 编号作为参数调用；用 gh issue view 抓取信息，用 gh api 查询 timeline 中的关联引用，用 gh api 增删标签。根据调查结果选择结论：已修复或内容已不存在则关闭并评论原因；本仓库可修复则添加 status/confirmed；属于供应商内容则添加 status/upstream 并指出上游仓库；无法判断则添加 status/needs-analysis。同时移除 status/triage（如存在），并按受影响内容添加一个（最多两个）area/ 标签，如 area/cli、area/compose、area/security 等。最后输出简短报告，说明问题、发现与下一步，并注明所执行的操作；issue 评论末尾需附上准确标明所用编码智能体的披露脚注。
适用场景：docker/docs 维护者或贡献者批量处理 issue 分诊时使用。
限制：仅适用于 docker/docs 仓库；需具备 gh 命令行工具及相应仓库权限；不要过度分类，旧 issue 若问题仍存在则不算过时；上游 issue 仍有效但本仓库无法直接修复；价格、平台支持等信息资料未提供。