用途：在推送后免手动盯守当前 PR 的 CI 检查，由持久 Monitor 流式推送每个状态变化，让会话在检查落地的同时继续工作，并按分类表逐事件响应。
核心边界：仅在动作是机械性（可逆、无需决策）时才不询问直接执行，例如干净冲突的 rebase、修 lint、推送、gh pr ready；任何判断类问题（修哪个发现、红灯测试、栈式重排、最终放行）都 STOP，交回用户。
CI 有三种状态并分别路由：green 推进、red 分类失败、conflict 重排或重基。
步骤 1 解析：用 gh pr view --json number,url,baseRefName,isDraft 找 PR（可传 [pr-number|url] 覆盖）；分支无 PR 且无参数则停止说明。Monitor 与通知工具为延迟加载，先执行 ToolSearch "select:Monitor,PushNotification"。
步骤 2 布防：布防轮询检查与可合并状态的 Monitor，每次状态变化发一事件。轮询命令 gh pr checks <pr-url> 与 gh pr view <pr-url> --json mergeable,mergeStateStatus；轮询间隔不低于 30 秒以避免 API 限流；按已加载的 Monitor schema 写 until 条件与间隔。
步骤 3 响应：全部必需检查绿时 PushNotification 并进入步骤 4；冲突且为孤立分支时 git rebase <baseRefName> + git push --force-with-lease；冲突且处于 git-spice 栈（gs ls 可列）时提议 gs stack restack + 级联推送并确认一次；冲突有残留标记则 STOP 交回；红灯仅为 lint/format 时用确定性修复（prettier --write / eslint --fix）提交推送；红灯为测试/类型检查时用 /pr-feedback 分诊，暴露 P1 并 STOP；红灯属已知 flaky 白名单（仅 i18n _latest in the merge queue，修复：运行 i18n:pull 后重跑）可重跑一次再升级。
步骤 4 绿灯：通知“PR 可供人工评审”；若仍是草稿，询问是否标记就绪（判断类 STOP），确认后 gh pr ready <pr-url>。注意：不要在任何检查仍为 pending/in_progress 时宣告全绿；绝不主动请求 GitHub 评审或发 Slack，公开征集团队由用户决定。
适用场景：管理单个 PR 的 CI 流程、自动化机械性修复、把判断权保留给用户。限制：部分命令、工具与栈式工具（gs）依赖具体环境，资料未提供安装与配置细节；已知 flaky 白名单仅列一条。