Sim 仓库 AI 评审保姆循环实践用 babysit Skill 把 PR 驱动到 Greptile 5/5 与零未决线程【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim导读本文基于 Sim 仓库.agents/skills/babysit/SKILL.md详解如何让 Agent 端到端看护一个 PR从触发评审、分诊真实缺陷、逐条回复并 resolve 线程、修复冲突与 CI 失败到反复重触发 Greptile 与 cubic 两个评审机器人直到达成Greptile Confidence Score 5/5 零未决评论线程 全部检查通过的干净状态。读完你可以掌握一套可直接运行的ghCLI GraphQL 驱动循环、双评审机器人行为差异的精确处置策略以及在此过程中保证分支始终可合并、公开仓库不泄露生产信息的硬性纪律。一、这个 Skill 解决什么问题在 Sim 仓库中PR 由两个行为完全不同的 AI 评审机器人共同把关Greptilegreptile-apps与 cubiccubic-dev-ai。人工逐个处理它们的行内评论、反复重新触发评审非常繁琐而只触发其中一个、或对陈旧评论盲目改代码都会让 PR 停留在看起来干净、实则没有的状态。babysitSkill 的目标就是把这个过程自动化成一个自循环loop由 Agent 全权负责 PR 从已创建到可干净合并之间的所有评审往来并特别设计为在/loop下运行——没有固定间隔以评审延迟为节奏自我推进从而在一次会话的多次唤醒之间存活下来。# .agents/skills/babysit/SKILL.md 的元信息 name: babysit description: Drive a PR to a clean review (Greptile 5/5, zero open threads) — ships if needed, keeps it mergeable against staging, re-triggers both Greptile and cubic, fixes real findings, replies to and resolves every thread, and loops until clean二、何时使用与输入Skill 的适用场景非常明确用户说 babysit this PR、keep working the reviews until its clean 或类似表述作为/ship的自然后续——当用户希望评审循环被自动化而不是自己手动重触发评审、逐条回复评论时。输入需要一个 PR 编号。如果用户没有给出编号且当前分支也没有已打开的 PR则必须先运行/ship创建 PR其中包含origin/staging同步检查详见 ship Skill。三、双评审机器人行为差异必须分别触发的两个系统两个机器人都会发布计入干净状态的行内评论线程且必须被分别重新触发——这是整个循环最容易踩坑的地方。Greptilegreptile-appscubiccubic-dev-ai结论形态摘要评论中的Confidence Score: X/5无评分只有行内线程摘要评论跨轮次原地编辑同一评论每次运行生成全新评审重新触发方式评论greptile评论cubic-dev-ai review this PR延迟1–3 分钟1–3 分钟每次 push 之后必须以两条独立评论分别触发两者。只触发 Greptile 是最常见的错误PR 显示 5/5但 cubic 在更早 commit 上留下的线程仍然打开其发现也从未针对修复重新检查。两个细节值得注意cubic-dev-ai review this PR是文档记录的触发词——单独的cubic不会触发它cubic 评审的是其运行开始时处于 HEAD 的 commit所以一条线程描述的代码可能已经被下一个 commit 改掉了。在把 cubic 的发现当作真实缺陷处理前先检查当前 HEAD 是否还存在该问题——陈旧轮次的正确处置是回复并 resolve而不是改代码。四、干净clean的精确定义循环的终止条件由以下三条同时成立决定缺一不可最新的 Greptile 摘要评论报告Confidence Score: 5/5reviewThreadsGraphQL见下文中来自任一机器人的线程isResolved: false的数量为零每个检查都已完成且通过——gh pr checks n中既无fail也无pending。第三条最容易被低估红色fail的 CI 无论如何都不算干净——仓库的 lint/audit 任务常常能抓到本地运行漏掉的问题而pending也不算干净——它还没有报告结果把未失败当作已通过会在 CI 表态之前就错误地宣布 PR 干净。必须等待第 10 步的停止条件覆盖了永不落定的检查。同时本轮没有新评论不能作为提前停止的理由一条线程可能来自更早的轮次而且 cubic 的第一批线程往往比 Greptile 晚一轮才出现。每次 push 后都要重新检查全部三个条件。五、核心循环十步驱动到干净Step 1 — 动手前先检查当前状态任何操作之前先检查 PR 现状包括是否仍可合并gh pr view n --json mergeable gh pr checks n | grep -v skipping gh pr view n --json comments -q [.comments[] | select(.author.logingreptile-apps)] | last | .body gh api graphql -f query query { repository(owner: owner, name: repo) { pullRequest(number: n) { reviewThreads(first: 50) { pageInfo { hasNextPage endCursor } nodes { id isResolved path line comments(first: 5) { nodes { id databaseId author { login } body } } } } } } }解读要点分数位于 Greptile最新评论的正文里| last | .body因为它跨轮次原地编辑同一评论reviewThreads(first: 50)只是一页——必须检查pageInfo.hasNextPage。若为true用after: endCursor重新执行同一查询并持续翻页直到hasNextPage为false再评估干净。超过 50 条线程的 PR 很罕见但在部分页上停下来会静默漏掉截止线之后的未解决线程该查询同时返回两个机器人的线程。ReviewThread自身没有作者——身份信息在评论上所以读取comments.nodes[0].author.login作为开启者不要在线程层级添加author字段否则查询无法编译。状态分派逻辑若mergeable为CONFLICTING先修复冲突进入 Step 2若有检查失败同样先修复——把它当作评审发现一样对待若有检查仍为pending不要评估干净——直接进入 Step 9 等待否则若 Greptile 5/5、跨所有页的每条线程isResolved: true、且每个检查都完成并通过则停止——按Reporting汇报结果并跳过后续步骤。Step 2 — 处理合并冲突如果 PR 有合并冲突合并origin/staging解决冲突运行常规 push 前检查push然后进入 Step 8 重新触发评审。Step 3 — 首次评审的等待全新 PR 没有机器人评论时两者在 PR 打开时会自动运行——通过gh pr checks n确认寻找Greptile Review与cubic · AI code reviewer在动手前等待两者都完成。它们完成时间不同所以只有一个报告了看起来干净并不代表干净。Step 4 — 分诊每个未决线程需要判断力不是机械循环评审轮次已落地但不干净时对每条isResolved: false的线程按其自身价值分诊真实缺陷用最干净的方式修复。修复前先匹配代码库对该类问题的既有惯例例如一个易受 SSRF 攻击的用户自供主机 fetch应当使用仓库其他地方对完全相同场景已经采用的validateUrlWithDNS/secureFetchWithPinnedIP模式——先 grep 一个解决同一问题的兄弟集成。绝不用 workaround、宽泛 try/catch 或 suppression 注释绕过发现——修复真正的根因误报不改代码。回复具体原因说明其为何不适用引用类型定义、其匹配的既有模式、或它遵循的文档让评审机器人和后来扫读的人都能理解为什么保持原样已被同轮更早的发现修复注明并 resolve不做重复的代码改动。Step 5 — 逐条回复绝不静默 resolvegh api repos/owner/repo/pulls/n/comments/databaseId/replies -f bodywhat was done and why然后通过 GraphQL 解决线程需要 Step 1 的线程id而不是评论 idgh api graphql -f querymutation { resolveReviewThread(input: {threadId: threadId}) { thread { isResolved } } }Step 6 — push 前重跑完整的/ship同步检查不只是那条 log 命令而是完整的 check-and-recover 流程必要时 stash 未提交改动、rebase、验证 rebase 没有只是干净地重放了游离 commit、若如此或有冲突则 cherry-pick 重建。详情见 ship Skill 的 Step 2。原因很实际跨长会话的 babysit 循环正是分支最容易漂移的场景——在未检测到的漂移之上叠加评审修复即使分支已经被修过一次也会产生超大 PR。随后按/ship的方式运行仓库的 pre-ship 检查不只是lint/typecheck/boundary-validation还包括 cleanup Skill若本轮修复触及 UI 代码与 db-migrate Skill若触及 schema/迁移这两个来自/shipStep 4、5 的条件门槛。一轮评审修复仍然是代码变更和原始 commit 一样可能绊倒任一门槛。Step 7 — 提交、push、push 后校验把本轮修复作为一个 commit提交。每当 Step 6 的同步检查重写了历史时使用--force-with-lease——包括一个无冲突完成、看似无害的普通git rebase origin/staging而不只是 cherry-pick 重建路径两者都重写了已发布到远程的 commit因此普通git push可能被拒绝。每一次 push 后不只是第一次都要运行/shipStep 9 的 post-push 校验git fetch origin staging git log --oneline --reverse origin/staging..HEAD gh pr view n --json commits -q .commits[].messageHeadline这两个列表必须描述同一组 commit。评审循环会跨多轮运行多次 push只在 push 前Step 6检查同步而从不检查之后正是坏 push 或 PR 提交历史在轮次之间悄然过期的疏漏来源。Step 8 — 分别重新触发两个评审机器人每条评论独立发布——合并成一条评论不能可靠地同时触发两者gh pr comment n --body greptile gh pr comment n --body cubic-dev-ai review this PR然后在等待之前确认两者都确实接单gh pr checks n应显示Greptile Review与cubic · AI code reviewer为pending。如果其中一个是上一轮的pass说明它的触发没有落地——重新发布那一条。Step 9 — 等待新一轮回到 Step 1用ScheduleWakeup以约300 秒的兜底延迟来等待——两个机器人需要 1–3 分钟而 CI 通常是三者中最慢的——绝不在 sleep 循环里忙轮询。每次唤醒都传入相同的/loop babysit PR n提示让循环正确恢复。Step 10 — 停止条件达到干净状态见上文定义或同一个未决发现或合并冲突连续两轮存活且没有新信息——此时向用户呈现而不是无限循环或用户中断。六、结束汇报Reporting循环结束时总结经过了多少轮实际修复了什么每条一行哪些被作为误报驳回及其理由最终状态——Greptile 分数、跨两个机器人的未决线程数、每个检查是否都完成并通过。七、公开仓库卫生发布即永久你在循环中发布的每条回复、评论、commit 都是公开且永久的评审机器人还会引用你的回复因此一次泄露就会扩散。/ship的 What to Omit类别清单与发布前 grep适用于本循环中的每一次发布。分诊发现时往往需要粘贴来自生产环境的证据——这正是规则最容易被违反的时刻。在发布回复前运行 grep而不是之后编辑一条评论并不能撤销其通知邮件。参考 grep 模式来自 ship Skillgrep -niE customer-or-company-name|[a-z0-9.-]\.(com|io|ai)|[0-9a-f]{8}-[0-9a-f]{4}-|\.sharepoint\.com|arn:aws|https?://[a-z0-9.-]*\.internal需要回避的内容包括客户/公司/用户名、workspace/user/org/KB/connector ID、邮箱地址生产或 staging 运维数据日志行、DB 行、指标、时间戳、事件详情、canary/告警输出基础设施细节主机名、ARN、内部 URL、环境变量值、密钥名以及逐字的客户内容文件名、文档标题、表/列名、文件夹路径。描述 bug 用机制而非发现方式Expired OAuth credentials fail to refresh in the worker 而不是 the Sheets canary failed at 16:31Z for workspace abc-123。需要用占位符替换真实示例real sheet name而非删掉——插图通常是最有价值的部分。八、硬性规则Hard Rules以下是本 Skill 明令禁止的事项也是循环能安全收敛的前提不先脱敏绝不把生产证据粘贴进回复见上不先回复绝不 resolve 线程绝不用 hacky workaround 修复发现——如果干净修复不明显就去代码库其他地方找解决同一类问题的兄弟模式并匹配它绝不静默丢弃发现——每条线程要么有代码修复要么有有理有据的回复绝不只重触发一个评审机器人——每次 push 后两者都要收到评论且开始等待前两者都要确认为pending每次 push 前都重跑/ship风格的同步检查而不仅是第一次。九、与仓库其他 Skill 的协作关系babysit不是孤立运行的它构建在仓库已有的工程流程之上ship Skill提供 PR 创建gh pr create --base staging、Step 2 同步检查与 Step 4/5 条件门槛/cleanup、/db-migrate、Step 9 post-push 校验、commit message 格式type(scope): description类型为fix/feat/improvement/chore与 AGENTS.md 中约定的提交规范一致以及 What to Omit 卫生规则——babysit 循环中的每一次 push 与发布都复用这套纪律cleanup Skill当本轮修复触及.tsx或apps/sim/components/、apps/sim/hooks/、apps/sim/stores/下的 UI 代码时必须先运行它以并行分析八个代码质量 passeffects、memo、callback、state、React Query、emcn、url-state、comments再顺序应用修复db-migrate Skill当本轮修复触及packages/db/migrations/**或packages/db/schema.ts时必须按 expand/contract 两阶段部署纪律审查迁移的零停机安全性并满足check:migrationsscripts/check-migrations-safety.ts的确定性门槛。一个评审修复轮次和原始 commit 一样是代码变更——跳过这些门槛等于把一个未经仓库标准把关的改动合入主干。十、落地前提与适用范围从源码与文档结构可以确认运行这套循环需要以下前提环境中可用ghCLI且已认证、具备对目标仓库执行gh pr view / checks / comment与 GraphQLapi调用的权限分支以staging为 PR 基线gh pr create --base staging同步检查围绕origin/staging展开目标仓库为公开仓库时全文的公开卫生规则必须逐条遵守本仓库即公开AGENTS.md 与 ship Skill 均为此做了专门约定循环本身通过/loop babysit PR n驱动的ScheduleWakeup保持存活而非固定定时器——以两个评审机器人与 CI 的实际延迟为节奏推进。这套设计把AI 评审闭环从一次性操作变成了可持续运行的自治流程判断力留给 Agent 分诊真实缺陷 / 误报 / 已修复机械部分重触发、分页、等待、校验、回复resolve交给明确的命令与状态机最终以 Greptile 5/5、零未决线程、全部检查通过为唯一退出标准。【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考