babysit
thedotmack/claude-mem
观察一个拉取请求或审查周期,直到它准备好合并。当被要求照看、监控或持续检查 PR 评论、审查意见和 CI 结果,直到所有可操作的问题都得到解决时,使用此功能。
...展开全部关于 babysit
持续监控一个拉取请求(Pull Request)或代码审查周期,直到其真正具备合并条件。在存在未解决的评论或审查线程时,它会持续进行检查,而不是在单次扫描后停止。该工作流会识别 PR 编号、分支以及基础分支,确认 PR 并非草稿状态,并检查可合并性、状态检查(checks)、审查意见、评论以及审查线程。挂起的状态检查会被持续监控直至完成,轮询间隔通常设定为 30 到 60 秒,除非用户指定了其他频率。系统会读取新评论和未解决的审查线程,并将机器人生成的摘要视为有用的但需通过代码验证的可操作发现。
针对真实问题修复的代码会被提交到独立的提交(commit)中,运行相关的测试或构建,推送更改后,流程会返回以重新检查状态。只有在验证代码或生成的工件(artifact)确实解决了相关评论后,才会解决陈旧的审查线程。仅当状态检查通过或被有意跳过、审查意见可接受、没有剩余的可操作评论且没有未解决的审查线程时,该过程才会停止。
该技能提供了具体的 GitHub CLI 和 GraphQL 配方。使用带有 JSON 字段列表的 gh pr view 命令可获得粗略状态,包括状态、草稿状态、可合并性、mergeStateStatus、reviewDecision、headRefOid 以及 statusCheckRollup。在发起 GraphQL 查询之前,使用 gh repo view 和 jq 解析仓库所有者和名称。使用包含 pageInfo 用于分页的 reviewThreads GraphQL 查询获取未解决的审查线程,文档中记录了使用 endCursor 在 hasNextPage 为真时分页遍历结果,并使用 jq 过滤出未解决的线程。resolveReviewThread 突变仅在验证修复措施后才会解决线程。操作规则包括在长时间的状态检查期间保持监控程序运行,确认机器人报告的问题是针对陈旧代码还是当前代码,在解决之前验证源代码和生成工件是否一致,进行全新的最终扫描,并报告具体证据,如最新的提交 SHA、检查结果、未解决线程数量、运行的测试以及任何未处理的本地脏文件。
常见问题解答
该技能在何时停止监控 PR?
仅当状态检查通过或被有意跳过、审查意见可接受、没有剩余的可操作评论且没有未解决的审查线程时,它才会停止。如果仍有开放的线程,它不会在单次状态检查通过后停止。
它多久轮询一次状态?
通常以 30 到 60 秒的实际间隔进行轮询,除非用户要求不同的频率。在长时间的状态检查仍在挂起时,会保持监控程序运行。
如何查找未解决的审查线程?
使用包含 pageInfo 的 GraphQL reviewThreads 查询,利用前一个 endCursor 在 hasNextPage 为真时分页遍历结果,然后使用 jq 过滤出 isResolved 为假的线程。
在何时解决陈旧的审查线程是安全的?
仅在验证代码或生成的工件现在确实解决了相关评论后,才使用 resolveReviewThread 突变进行解决。对于分布式生成的文件,必须首先确认源代码和生成工件是一致的。
最后应该报告什么?
具体证据:最新的提交 SHA、检查名称和结果、未解决线程数量、运行的测试,以及经过对 PR 状态、线程、最近评论和 git 状态进行一次全新扫描后,遗留的任何未处理的本地脏文件。
Stay with the PR until it is actually clean. Do not stop after one check pass if comments or review threads are still unresolved.
Workflow
- Identify the PR number, branch, and base branch.
- Confirm the PR is not draft and inspect mergeability, checks, review decision, comments, and review threads.
- Watch pending checks until they finish. Poll at a practical interval, usually 30-60 seconds unless the user asks for a different cadence.
- Read new comments and unresolved review threads. Treat bot summaries as useful, but verify actionable findings against the code.
- Fix real issues in focused commits, run relevant tests/builds, push, and return to step 2.
- Resolve stale review threads only after verifying the code or generated artifact now addresses the comment.
- Stop only when checks are passing or intentionally skipped, review decision is acceptable, no actionable comments remain, and no unresolved review threads remain.
GitHub CLI Checks
Use gh pr view for the coarse status:
gh pr view <number> --json \ number,state,isDraft,mergeable,mergeStateStatus,reviewDecision,headRefOid,statusCheckRollup,url
Resolve the repository owner/name before using GraphQL:
repo_json=$(gh repo view --json owner,name)owner=$(jq -r '.owner.login // .owner.name' <<<"$repo_json")repo=$(jq -r '.name' <<<"$repo_json")
Use GraphQL for unresolved review threads. Include pageInfo; omit cursor on the first page, then pass the previous endCursor with -f cursor="$cursor" while hasNextPage is true.
gh api graphql \ -f query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}' \ -f owner="$owner" -f repo="$repo" -F number=<number>
Use this loop when a PR may have many review threads:
thread_query='query($owner:String!,$repo:String!,$number:Int!,$cursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$cursor){pageInfo{hasNextPage endCursor}nodes{id,isResolved,isOutdated,path,line,comments(last:1){nodes{author{login},body,createdAt,url}}}}}}}'cursor_args=()while :; do page=$(gh api graphql -f query="$thread_query" -f owner="$owner" -f repo="$repo" -F number=<number> "${cursor_args[@]}") printf '%s' "$page" | jq -r '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false) | [.id,.path,(.line//""),(.isOutdated|tostring),(.comments.nodes[-1].author.login//""),(.comments.nodes[-1].body|gsub("";" ")|.[0:240])] | @tsv' jq -e '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' >/dev/null <<<"$page" || break cursor=$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.endCursor' <<<"$page") cursor_args=(-f cursor="$cursor")done
Filter unresolved threads with jq:
jq -r '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved==false) | [.id,.path,(.line//""),(.isOutdated|tostring),(.comments.nodes[-1].author.login//""),(.comments.nodes[-1].body|gsub("";" ")|.[0:240])] | @tsv'
Resolve a stale thread only when the fix is verified:
gh api graphql \ -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{id,isResolved}}}' \ -f threadId=<thread-id>
Operating Rules
- Keep the watcher running while long checks are pending.
- If a generated file is part of the distribution, verify the source and generated artifact agree before resolving comments.
- If a bot reports an issue against stale code, confirm whether the thread is outdated or addressed in the latest head.
- Before final reporting, do one fresh sweep of PR status, unresolved threads, recent comments, and local
git status. - Report concrete evidence: latest commit SHA, check names and results, unresolved thread count, tests run, and any dirty local files left untouched.





首页
