用途：在用户希望逐条讨论、质疑并决定 pull request 评审意见、且在做任何代码改动前先完成讨论时使用。它把评审反馈当作待检验的主张，而不是无条件接受的指令。
主要能力：在改动代码或发布远程回复前完成预检；同时收集未解决的评审线程与顶层 issue 评论；仅过滤明显的机器人汇总、状态通知、重复确认和纯表情评论，保留机器人作者提出的实质意见。一次只讨论一条评论或一个已确认的级联问题，讨论后立即持久化决定。使用 .pr-review/triage.json 作为可续跑的本地台账，写入状态后需确认该目录已 gitignore，否则先询问用户。
使用方式：优先使用 gh CLI，PR 分支需已本地检出，仓库文档化的保障命令需可发现且可运行。识别 PR 使用 gh pr status、gh pr view；检查 PR 正文漂移用 base=$(gh pr view <pr-number> --json baseRefName --jq '.baseRefName') 与 git log "origin/$base..HEAD" --oneline，以及 gh pr view <pr-number> --json body --jq '.body'。每条意见按证据卡结构呈现反馈、代码与约定证据、前提检查、临时评估和待决问题，每轮最多问一个聚焦问题。分类包括 MUST_FIX、SHOULD_FIX、PARK、OUT_OF_SCOPE、NEEDS_CLARIFICATION。最终分类获得明确批准后，先处理 MUST_FIX，再处理 SHOULD_FIX，级联问题原子处理，每次聚焦提交一条 Conventional Commit 并在正文点名评审者，推送后回复原评论并用 GET 验证，验证通过才可解决线程。最后发布一条汇总 PR 评论。
限制：这是一种刻意较慢的流程，价值在于判断而非速度。不得使用 git reset --hard、git checkout -- 等破坏性命令，不得回滚本次运行之前已有的改动。未获最终批准前不得编辑文件、创建计划、回复、解决线程、提交或推送。不得把未解决的前提变成静默假设，不得用 NEEDS_CLARIFICATION 回避困难工作。不得批量预先分类所有评论，不得把无关反馈合并为一个提交，不得在回复验证前解决线程。远程写入命令超时后不得推断成功，重试前应先重新获取远程对象，避免重复回复或重复汇总。若资料未提供价格、平台要求或额外面向用户的效果信息，此处暂未提供。