Heim

Skill

Codeüberprüfung

babysit

thedotmack/claude-mem

Sehen Sie sich einen Pull Request oder Review-Zyklus an, bis er bereit zum Zusammenführen ist. Verwenden Sie diese Option, wenn Sie aufgefordert werden, einen PR zu „beaufsichtigen“, zu überwachen oder die PR-Kommentare, Reviews und CI kontinuierlich zu prüfen, bis alle umsetzbaren Probleme gelöst sind.

...Alle erweitern

Zeit aktualisiert 26. August 2026

# automation # github # code-review # pull-request # ci # Code ReviewGit & Version ControlProductivity & Workflow

Über babysit

Überwacht einen Pull Request oder Review-Zyklus, bis er wirklich bereit zum Zusammenführen ist, und fährt fort zu prüfen, anstatt nach einem einzelnen Durchlauf aufzuhören, solange Kommentare oder Review-Threads ungelöst bleiben. Der Workflow identifiziert die PR-Nummer, den Branch und den Basis-Branch, bestätigt, dass der PR kein Entwurf ist, und prüft die Zusammenführbarkeit, Checks, die Review-Entscheidung, Kommentare und Review-Threads. Ausstehende Checks werden überwacht, bis sie abgeschlossen sind, wobei in einem praktischen Intervall von etwa 30 bis 60 Sekunden abgefragt wird, es sei denn, der Benutzer fordert ein anderes Intervall. Neue Kommentare und ungelöste Review-Threads werden gelesen, wobei Bot-Zusammenfassungen als nützliche, aber umsetzbare Erkenntnisse behandelt werden, die gegen den Code verifiziert werden.

Reale Probleme werden in fokussierten Commits behoben, relevante Tests oder Builds werden ausgeführt, Änderungen werden gepusht und der Zyklus kehrt zurück, um den Status erneut zu inspizieren. Veraltete Review-Threads werden nur gelöst, nachdem verifiziert wurde, dass der Code oder das generierte Artefakt den Kommentar nun adressiert. Der Prozess stoppt nur, wenn Checks bestanden oder absichtlich übersprungen werden, die Review-Entscheidung akzeptabel ist, keine umsetzbaren Kommentare mehr vorhanden sind und keine ungelösten Review-Threads mehr bestehen.

Das Skill bietet konkrete GitHub CLI- und GraphQL-Rezepte. gh pr view mit einer JSON-Feldliste gibt einen groben Status einschließlich Zustand, Entwurfsstatus, Zusammenführbarkeit, mergeStateStatus, reviewDecision, headRefOid und statusCheckRollup aus. Der Repository-Besitzer und -Name werden mit gh repo view und jq vor GraphQL-Abfragen aufgelöst. Ungelöste Review-Threads werden mit einer reviewThreads-GraphQL-Abfrage abgerufen, die pageInfo für die Paginierung enthält, mit einer dokumentierten Schleife, die Ergebnisse paginiert, indem endCursor verwendet wird, solange hasNextPage wahr ist, und ungelöste Threads mit jq filtert. Eine resolveReviewThread-Mutation löst einen Thread nur auf, wenn die Behebung verifiziert ist. Betriebsregeln umfassen das Laufenlassen des Watchers während langer Checks, die Bestätigung, ob von Bot gemeldete Probleme gegen veralteten oder aktuellen Code verstoßen, die Verifizierung, dass Quelle und generierte Artefakte übereinstimmen, bevor aufgelöst wird, eine frische finale Durchsuchung und die Berichterstattung über konkrete Beweise wie die neueste Commit-SHA, Check-Ergebnisse, Anzahl der ungelösten Threads, ausgeführte Tests und alle schmutzigen lokalen Dateien.

FAQ

Wann hört das Skill auf, einen PR zu überwachen?

Nur wenn Checks bestanden oder absichtlich übersprungen werden, die Review-Entscheidung akzeptabel ist, keine umsetzbaren Kommentare mehr vorhanden sind und keine ungelösten Review-Threads mehr bestehen. Es stoppt nicht nach einem einzelnen Check-Durchlauf, wenn Threads noch offen sind.

Wie oft wird nach dem Status abgefragt?

In einem praktischen Intervall, normalerweise 30 bis 60 Sekunden, es sei denn, der Benutzer fordert ein anderes Intervall. Der Watcher wird während langer ausstehender Checks weiter ausgeführt.

Wie werden ungelöste Review-Threads gefunden?

Mit einer GraphQL-reviewThreads-Abfrage, die pageInfo enthält, wobei Ergebnisse durch Paginierung unter Verwendung des vorherigen endCursor durchlaufen werden, solange hasNextPage wahr ist, und dann Threads gefiltert werden, bei denen isResolved falsch ist, mit jq.

Wann ist es sicher, einen veralteten Review-Thread aufzulösen?

Nur nachdem verifiziert wurde, dass der Code oder das generierte Artefakt den Kommentar nun adressiert, unter Verwendung der resolveReviewThread-Mutation. Für verteilte generierte Dateien muss zuerst bestätigt werden, dass Quelle und generiertes Artefakt übereinstimmen.

Was sollte am Ende gemeldet werden?

Konkrete Beweise: die neueste Commit-SHA, Check-Namen und -Ergebnisse, die Anzahl der ungelösten Threads, ausgeführte Tests und alle schmutzigen lokalen Dateien, die unberührt bleiben, nach einer frischen Durchsuchung des PR-Status, der Threads, der neuesten Kommentare und des Git-Status.

Auf GitHub ansehen

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.