用途：在保持主代理上下文精简的前提下，运行可复用的 GitHub PR 监控循环，持续跟踪 CI 检查、审查评论、PR 会话评论、审查状态、合并冲突与分支新鲜度。
输入与状态：需要 PR 编号或 URL，以及可选的工作流就绪条件（如必需标签、必需审批机器人、超时规则）。不传 --state-file 时，脚本首次运行会自动在 .agents/skills/pr-monitoring-loop/scripts/state/.pr-monitor-<pr>.json（已 gitignore）创建状态文件，并在后续调用中复用，从而跨子代理区分新旧反馈。仅需隔离状态时（如并行监视同一 PR 的不同分支或测试）才用 --state-file <path> 覆盖；传 --no-state 可完全禁用持久化。不要将状态放在 .git/ 下，因为该仓库使用 git worktree，.git 是指向特定 worktree 的文件，会导致状态碎片化。
主要能力：脚本 scripts/check-pr-state.py 输出聚焦 JSON，包含 pr、checks、comments、threads、threadDetails、reviews、verifyOpenspec、merge、actionable、hasActionable、headPushedRecently 等字段。默认不返回原始数据数组，需要时用 --full-payload。新工作由 comments.newIssueComments、comments.newReviewComments、threads.unresolvedNew、threads.unresolvedUpdatedSinceHead、reviews.newReviewIds 等字段体现，旧总数仅供参考，不能驱动可操作决策。审查状态看 reviews.effectiveDecision（每位审查者的最新审查，较新的 APPROVED 会取代较早的 CHANGES_REQUESTED）。CI 看 checks（优先 commit-pinned 数据而非 gh pr checks 汇总）。
使用方式：主代理为 PR 启动一个具备写能力的委托子代理，让其调用监控脚本并在出现可操作项（CI 失败、新评论、未解决审查线程、CHANGES_REQUESTED、合并冲突或分支过时）时继续。简单修复（机械 lint、格式化、生成产物、明显测试期望更新、小笔误等）可由子代理直接实现、提交、推送，并按线程解决协议回复与解决相应线程，然后继续监控新 head。非简单、含糊、有风险、跨多关切、需产品/API 判断、重复失败或需用户输入的情况，返回主代理处理，由其启动新的委托子代理，并始终传入相同的 --state-file，使 seen ID 保持。
节奏与退出：优先使用 --watch 而非手写 sleep 循环。活跃 CI 窗口用 --watch --interval 60，仅剩长时间作业时用 --watch --interval 300，并始终设置 --max-duration。--watch 在首个可操作 tick 退出码 0，超时 124，重试后仍失败的瞬时 gh 错误为 2（应视为下个 tick 重试，而非阻塞）。每次 push 后应为新 PR head 重启监控周期。
线程解决：委托修复后必须两步——先线程回复引用提交 SHA 与一行摘要，使用线程首条评论的 REST databaseId 作为 in_reply_to，再通过 GraphQL 用线程节点 id 解决该线程。禁止只解决不回复，也不要解决未实际处理的线程。
限制与注意：verify-openspec 行为为可选，除非调用方明确要求，否则不要添加 verify-openspec 标签、等待校验批准或应用 OpenSpec 专属完成规则。仅在 requiresOpenspecVerification 为 true 时应用标签；因工作流会在接手后自行移除标签，判断是否重新触发应读 runState 而非 pr.labels。仅当 runState == "approved" 且 checks.failed == 0 才算成功，不要以 pr.reviewDecision == "APPROVED" 或绿色 verify 检查等同视之。除用户明确要求外不得 force-push。可用 python -m pytest .agents/skills/pr-monitoring-loop/scripts/tests 运行测试套件。执行各类所需费用、额度、具体平台限制等资料暂未提供。