review-loop 用于让 Agent 自动把一个 PR 及其同源的 backport PR 推进到“通过检查且无遗留 Copilot 发现项”的可评审状态，并在标题末尾追加 [ready] 标签，整个过程从不合并 PR。
适用场景：用户希望获得“让这个 PR 通过评审并变绿”的免手动流程；变更横跨一个主 PR 与一个或多个 backport--to-stable/ PR，需要保持同步。
前置条件：gh 已认证（gh auth status），并对循环涉及的操作具备权限：pull-requests: write（请求评审、编辑标题）、issues: write（增删 skip_all 标签）、actions: write（取消/重跑工作流）；一个具备 repo + workflow 范围的经典令牌即可覆盖。PATH 中需有 go ≥ 1.23。工作目录位于目标仓库内，且功能分支已推送。
用法：编排逻辑由 ci-feedback-loop CLI 承担，需在每个 shell 中定义别名： ci_fb() { (cd "$(git rev-parse --show-toplevel)/.github/skills/ci-feedback-loop" && go run . "$@"); } 每个 ci_fb review 子命令接受相同的可选 PR 引用（123、#123 或 PR URL），未给出时回退到当前分支的 PR；每个子命令都会把每个种子的开放 backport 一并展开。可用 ci_fb review prs 列出将要驱动的 PR 集合。
流程概要：先执行 ci_fb review pause 添加 skip_all、去掉 [ready] 标签并取消进行中的运行；随后按 code-quality-review 技能自审 diff 并应用认可的意见；再请求 Copilot 评审（部分仓库推送即自动请求，否则用 gh pr edit "$n" --add-reviewer copilot-pull-request-reviewer）；用 ci_fb review state 检查评审是否落地；用 ci_fb review findings 读取并逐条处理发现项（在代码中最小修复，或用 gh api 在对应线程回复理由，绝不静默忽略，线程解决交给人类）；提交修复后重复评审；之后 ci_fb review resume --rerun 重启测试，按 ci-feedback-loop 流程观察，失败则定位并做最小修复后回到步骤 1；成功则用 ci_fb review ready 追加 [ready] 标签，该命令在仍有 skip_all 或存在失败/待定检查时会拒绝执行。
限制与约定：绝不合并；不要在步骤 2 之前请求 Copilot 评审；不要为了变绿而跳过或禁用检查，也不要对 ci_fb review ready 使用 --force；不要对长时间轮询阻塞会话。相关约定见 AGENTS.md 中的“PR review rules”“CI cost and skip labels”“Agent collaboration rules”。