Monitor a pull request through review and CI until it's green: verify every bot claim against the code, fix what's real, push back on what's wrong, rerun flaky checks. Use when the user asks to babysit, monitor, watch, or shepherd a PR, says "get this PR green" or "handle the review comments". Accepts an optional PR number/URL; defaults to the current branch's open PR.
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
The repos we work in have AI review bots. They're helpful, even if they are not always right. Treat every bot comment as a hypothesis, not a finding: read the code it points at before acting on it.
First check gh pr view <n> --json isDraft. Review bots skip draft PRs
(CodeRabbit posts "Review skipped: Draft detected"), so on a draft there is
no bot review to wait for. Either ask the user whether to mark it ready
(gh pr ready <n>), or trigger one manual review with a single
@coderabbitai review comment. Trigger ONCE and wait: repeat triggers do
nothing ("Already reviewed") or hit the fair-usage rate limit, and each
attempt leaves a spam comment on the PR. When babysitting several draft PRs,
stagger the triggers well apart (the limit is adaptive and shared across the
org); expect some reviews to take an hour or more to land, and just wait —
re-commenting does not speed it up.
If your harness offers tools to monitor a PR, use them so you can respond
when comments arrive. Otherwise, poll: gh pr checks <n> --watch in the
background covers CI, and check for new comments on a relaxed interval.
Only act on checks and comments newer than the latest push — anything older is already handled or already obsolete.
For each comment: fix it if it's a real bug. If it's wrong, reply with
evidence (file:line, the actual behavior) and resolve the thread. If it's
real but beyond the PR's goal, acknowledge it and file a follow-up issue
instead. Human reviewers outrank bots — address their requests, and never
resolve their threads for them.
For CI failures, read the failing log (gh run view <id> --log-failed).
Fix what this PR caused. Rerun a flaky check once (gh run rerun <id> --failed); if it fails again, it's real. If it's broken on the base branch
too, report it to the user — that's not this PR's job.
Push fixes as new commits; a reviewed branch keeps its history. Reply to
inline comments in their thread, never as a top-level PR comment
(gh pr comment can't do this — use GraphQL):
# list threads with resolution state
gh api graphql -f query='query($o:String!,$r:String!,$n:Int!){repository(owner:$o,name:$r){pullRequest(number:$n){reviewThreads(first:100){nodes{id isResolved path line comments(first:10){nodes{author{login} body createdAt}}}}}}}' -F o=<owner> -F r=<repo> -F n=<pr>
# reply in a thread
gh api graphql -f query='mutation($t:ID!,$b:String!){addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:$t,body:$b}){comment{url}}}' -F t=<thread-id> -f b='<reply>'
# resolve a thread
gh api graphql -f query='mutation($t:ID!){resolveReviewThread(input:{threadId:$t}){thread{isResolved}}}' -F t=<thread-id>
Screenshots and short recordings help when the fix is visual.
Do not let review feedback expand the PR beyond the user's original goal. Address real shortcomings, but avoid scope creep.
If nothing has changed, stay quiet rather than posting filler comments. Stop when the review bots and required checks are green on the latest commit. Merge only when the user explicitly requested it; otherwise report that the PR is ready.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.
中文简介正在准备中。当前显示原文说明。
Generate a single unified changelog from git history that works for everyone in the company (managers and non-tech colleagues as well as developers). Outputs Slack mrkdwn so it can be pasted straight into Slack. Defaults to Slovak (English only on explicit request) and to comparing the release branch (main) against develop to show unreleased changes; also supports date ranges like "today", "yesterday", "last week", or an explicit git range. User-invoked only via /changelog.
中文简介正在准备中。当前显示原文说明。
Create atomic git commits with terse, exact Conventional Commits messages. Cuts noise, preserves intent. Subject ≤50 chars. Body only when "why" isn't obvious. Use when the user says "commit", "commit this", "/commit", or asks to stage and commit changes.
中文简介正在准备中。当前显示原文说明。
Create atomic git commits with terse Conventional Commits messages, then push to remote. Subject ≤50 chars, body only when "why" isn't obvious. Never force pushes. Use when the user says "commit and push", "commit & push", "/commit-push", or asks to stage, commit, and push in one flow.
中文简介正在准备中。当前显示原文说明。
Create branch, atomic commits, push, and open a pull request with terse, exact messages. Conventional branch + commit format. PR title ≤70 chars, body says "why", not "what". Use when the user says "create pr", "create pullrequest", "create pull request", "make pr", "open pr", "open pullrequest", "open pull request", "submit pr", "raise pr", "/create-pr", or asks to ship/send changes as a pull request (PR/pullrequest/pull-request, any spelling).
中文简介正在准备中。当前显示原文说明。
Type-safe ORM for Cloudflare D1 using Drizzle. Use when building D1 schemas, writing type-safe queries, generating migrations with Drizzle Kit, defining relations, using db.batch, or hitting D1_ERROR, BEGIN TRANSACTION failures, foreign key constraints, env.DB undefined, or schema inference issues.
中文简介正在准备中。当前显示原文说明。