用途：帮助开发者系统化处理 GitHub Pull Request 上的评审反馈，包括代码评审意见、评审者评论与机器人评论。
主要能力：抓取未解决的评审线程、PR 普通评论与机器人评论并过滤噪声；为每条评论分配处置方式（fix、doc-only、skip、defer）；以编号表格提出计划并等待用户按行号修改确认；按关注点分组应用改动（docs、tests、api、error-handling、refactor）；使用 Conventional Commits 分组提交，全部完成后一次性 push；为延后项创建后续 issue，回复每个线程并解决已修复、仅文档和延后的线程。
使用方式：依赖 gh CLI。先获取 PR 元数据（gh pr view --json ...），再用 gh api graphql 查询 reviewThreads，用 gh api repos/OWNER/REPO/issues/PR_NUMBER/comments 获取普通评论。评估后输出计划表，用户按行号编辑（如 2 skip: flaky on CI）。提交时用 git rev-parse HEAD 记录完整 40 位哈希，回复模板中引用该哈希；延后项先用 gh issue create 创建 issue 并捕获 URL，再回复。回复内联线程用 pulls/PR_NUMBER/comments/COMMENT_ID/replies，COMMENT_ID 须用 databaseId 而非 node id；解决线程用 resolveReviewThread mutation。
适用场景：需要批量、有条理地响应 PR 评审意见并保持提交历史清晰的开发工作流。
限制：reviewThreads(first:100) 与 comments(first:50) 不分页，超出会被静默截断，需警告用户；分支与远端不同步时交由用户处理，不自动 rebase 或强推；存在合并冲突时在应用改动前停止并询问；过时内联评论标记 [outdated] 并默认跳过；用户拒绝整个计划时不提交、不回复、不创建 issue。