agentleFS
NVIDIAKnown publisherNVIDIA/TensorRT-Model-Connect/plugins/trtmc-agent-skills/skills/pr-babysitter/SKILL.md

pr-babysitter

Skill290 starsChanged 45 days agoApache-2.0View on GitHub

Use when monitoring GitHub pull request CI, diagnosing failed checks, rebasing branches onto github/main, applying narrowly scoped fixes, and updating PRs until their latest checks are green or a human blocker is identified.

  • Commits and pushes

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

38 rules. 0 are common, 21 are distinctive, and 17 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 21

    Distinctive

    This author's own choices. Worth a look.

  • 17

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Use the github remote and target main.

    line 19
  2. Distinctive:

    Never push to main.

    line 20
  3. Distinctive:

    Never change unrelated PR branches.

    line 21
  4. Distinctive:

    Do not rewrite a PR's intent during rebase.

    line 22
  5. Distinctive:

    Do not skip CI unless the user explicitly asks.

    line 24
  6. Very specific:

    Never request, enable, or queue GitHub auto-merge.

    line 25
  7. Distinctive:

    When merge authority is granted, merge only after the latest CI for the current PR head has completed successfully and the PR is mergeable.

    line 27
  8. Distinctive:

    Treat GitHub branch protection and rulesets as insufficient evidence of CI safety.

    line 29
  9. Very specific:

    Use $write-git-messages for fix commits, PR comments, and squash or rebase text.

    line 32
  10. Distinctive:

    If a fix needs unavailable hardware, product judgment, or broad scope, stop and report the blocker.

    line 34
  11. Very specific:

    Read .github/workflows/internal-ci-bridge.yml from current github/main.

    line 39
  12. Distinctive:

    Before triggering premerge, capture the current PR metadata head and inspect its existing protected status:

    line 43
  13. Very specific:

    If a label event was created for an older SHA, let the bridge report the superseded trigger, wait for Community CPU / Required on the …

    line 61
  14. Very specific:

    When authorization fails and leaves run-internal-ci attached, remove it before adding it again.

    line 64
  15. Very specific:

    Only an actor whose repository permission is maintain or admin may add the one-shot trigger.

    line 67
  16. Very specific:

    Never use the legacy run-ci label.

    line 70
  17. Very specific:

    If the current exact head is already PENDING or PASS, do not add the trigger again.

    line 92
  18. Distinctive:

    If the head changes, treat the old result as stale and trigger the new head once.

    line 94
  19. Distinctive:

    Never trigger premerge after the PR has merged.

    line 97
  20. Distinctive:

    Use a short-lived lock for long monitoring cycles:

    line 103
  21. Distinctive:

    Remove it before exiting:

    line 117
  22. Distinctive:

    Only merge when the user has explicitly authorized merging.

    line 161
  23. Distinctive:

    Before merging, verify all of the following against the latest PR head:

    line 168
  24. Very specific:

    Every expected CI check in statusCheckRollup has completed with conclusion SUCCESS.

    line 176
  25. Distinctive:

    If a new commit lands after checks pass, restart the wait.

    line 181
  26. Very specific:

    If gh pr checks exits nonzero, including exit code 8 for pending checks, do not merge.

    line 186
  27. Very specific:

    Do not infer safety from mergeable=MERGEABLE, an allowed merge button, a ruleset that lacks required status checks, or successful local …

    line 191
  28. Very specific:

    Use an explicit merge command only after those checks pass.

    line 195
  29. Very specific:

    After merging, verify the PR state is MERGED and report the merge commit.

    line 207
  30. Distinctive:

    Do not overwrite a dirty user checkout.

    line 212
  31. Distinctive:

    Before a history rewrite, record the exact remote branch SHA.

    line 231
  32. Distinctive:

    Use Source Actions logs only for the retained Source workflows: Internal CI Bridge and Pages.

    line 244
  33. Very specific:

    Keep downloaded Internal evidence local and private.

    line 274
  34. Very specific:

    Read the PR diff first with git diff github/main...HEAD.

    line 291
  35. Distinctive:

    Run the most relevant local verification available.

    line 293
  36. Very specific:

    Use $write-git-messages for a clear commit message that complies with the repository ruleset.

    line 294
  37. Distinctive:

    Add a PR comment only when it communicates root cause, validation, or a blocker not already visible from commits.

    line 297
  38. Distinctive:

    Always include a complete cycle summary:

    line 302

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

PR Babysitter

Purpose

Monitor open non-draft GitHub PRs, classify their CI state, rebase when they are behind main, diagnose failed checks, make minimal fixes on the PR source branch, and push updated commits. Work sequentially and report every PR state.

Ground Rules

  • Use the github remote and target main.
  • Never push to main.
  • Never change unrelated PR branches.
  • Do not rewrite a PR's intent during rebase. Preserve the feature and adapt it to current main.
  • Do not skip CI unless the user explicitly asks.
  • Never request, enable, or queue GitHub auto-merge. Do not use gh pr merge --auto or any equivalent API flag.
  • When merge authority is granted, merge only after the latest CI for the current PR head has completed successfully and the PR is mergeable.
  • Treat GitHub branch protection and rulesets as insufficient evidence of CI safety. The repository may allow a squash or rebase merge while checks are still queued, pending, running, or absent; that is still forbidden here.
  • Use $write-git-messages for fix commits, PR comments, and squash or rebase text.
  • If a fix needs unavailable hardware, product judgment, or broad scope, stop and report the blocker.

Current CI Contract

Read .github/workflows/internal-ci-bridge.yml from current github/main. Source keeps only Internal CI Bridge and Pages workflows. Premerge, including legal compliance, and nightly execution stay in private Internal CI.

Before triggering premerge, capture the current PR metadata head and inspect its existing protected status:

REPOSITORY=NVIDIA/TensorRT-Model-Connect
PR_NUMBER=<number>
pull=$(gh api "repos/$REPOSITORY/pulls/$PR_NUMBER")
PR_HEAD_SHA=$(jq -er '.head.sha' <<<"$pull")
gh api \
  "repos/$REPOSITORY/commits/$PR_HEAD_SHA/status" \
  --jq '[.statuses[] |
    select(.context == "TRTMC Internal CI / Automated premerge gate")][0]'

gh pr edit "$PR_NUMBER" \
  --repo "$REPOSITORY" \
  --add-label run-internal-ci

If a label event was created for an older SHA, let the bridge report the superseded trigger, wait for Community CPU / Required on the current PR head, and retry. When authorization fails and leaves run-internal-ci attached, remove it before adding it again; adding an existing label does not emit another label event.

Only an actor whose repository permission is maintain or admin may add the one-shot trigger.

Never use the legacy run-ci label. The bridge consumes run-internal-ci, verifies the open PR targets main, and rechecks the event SHA, PR metadata SHA, and a successful Community CPU / Required job for that head before dispatching only pr_number and head_sha. The label path does not wait for the later Community GPU stage.

Internal CI resolves and tests the exact pull-request merge whose first parent is the current main revision and whose second parent is the authorized PR head. It publishes the sanitized result on that exact head SHA.

The Source-visible premerge result is only the sanitized TRTMC Internal CI / Automated premerge gate status on that exact head: PENDING, then PASS or FAIL, with a target URL on the pull request's checks page. A successful bridge dispatch is not a successful premerge result.

Raw logs, artifacts, internal packages, runner details, and nightly execution stay private. Never copy them into Source Actions, Source artifacts, status target URLs, or PR comments. A source-head guard failure is the exception to the no-comment norm: the bridge publishes only the public event/PR/branch SHA diagnostic, recovery instruction, and Source workflow link. It updates one marked comment instead of creating repeated comments.

  • If the current exact head is already PENDING or PASS, do not add the trigger again.
  • If the head changes, treat the old result as stale and trigger the new head once.
  • Retry a failed unchanged head only with explicit rerun authorization.
  • Never trigger premerge after the PR has merged. A merge does not rerun the same premerge suite; Pages and scheduled Internal nightly follow independent paths.

Lock Guard

Use a short-lived lock for long monitoring cycles:

LOCK_FILE="/tmp/trtmc_pr_babysitter.lock"
if [ -f "$LOCK_FILE" ]; then
  lock_age=$(( $(date +%s) - $(stat -c %Y "$LOCK_FILE" 2>/dev/null || echo 0) ))
  if [ "$lock_age" -lt 3600 ]; then
    echo "Previous PR babysitter cycle still running."
    exit 0
  fi
fi
touch "$LOCK_FILE"

Remove it before exiting:

rm -f "$LOCK_FILE"

Survey PRs

Fetch current state dynamically. Do not hardcode PR numbers.

git fetch github main --prune
gh pr list \
  --repo NVIDIA/TensorRT-Model-Connect \
  --state open \
  --json number,title,headRefName,baseRefName,isDraft,mergeStateStatus,reviewDecision,statusCheckRollup,headRepositoryOwner

Skip draft PRs and PRs not targeting main unless the user asked for them.

For a specific PR:

gh pr view <number> \
  --repo NVIDIA/TensorRT-Model-Connect \
  --json number,title,headRefName,baseRefName,isDraft,mergeStateStatus,reviewDecision,statusCheckRollup,commits,files,url

gh pr checks <number> --repo NVIDIA/TensorRT-Model-Connect

Classify

StateAction
Checks pending/runningWait; do not push noise; never request auto-merge
Checks green and branch currentMerge if merge authority was granted; otherwise report OK
Checks green but branch behind mainRebase and push
Checks failed and branch behind mainRebase first, then diagnose/fix
Checks failed and branch currentDiagnose/fix
Merge conflictsRebase locally if mechanical; otherwise report blocker
Missing required reviewReport waiting on review

Merge After CI

Only merge when the user has explicitly authorized merging. Never treat auto-merge as a way to wait for CI. A gh pr merge --auto invocation has previously merged immediately while a check was still queued because the repository ruleset did not require status checks. Auto-merge is forbidden for this skill. This is an agent-side hard gate: if GitHub would allow the merge before CI is green, do not merge anyway.

Before merging, verify all of the following against the latest PR head:

  • gh pr checks <number> --repo NVIDIA/TensorRT-Model-Connect --watch --interval 30 exits successfully.
  • gh pr view <number> --repo NVIDIA/TensorRT-Model-Connect --json headRefOid,mergeable,mergeStateStatus,statusCheckRollup shows the same head SHA whose checks passed.
  • mergeable is MERGEABLE and mergeStateStatus is clean enough for the repository ruleset, such as CLEAN.
  • Every expected CI check in statusCheckRollup has completed with conclusion SUCCESS. Treat QUEUED, PENDING, IN_PROGRESS, WAITING, REQUESTED, empty conclusion, missing check rollup, skipped unexpectedly, or failing as a merge blocker.
  • The same completed successful check set belongs to the current headRefOid. If a new commit lands after checks pass, restart the wait.
  • The current head has a successful TRTMC Internal CI / Automated premerge gate commit status. A green bridge run, a result on an older head, or a ruleset without required status checks does not satisfy this gate.

If gh pr checks exits nonzero, including exit code 8 for pending checks, do not merge. If any check is pending or queued, wait and poll. If any check fails, diagnose and fix it. If no CI checks are reported for the head SHA, report a human blocker instead of merging.

Do not infer safety from mergeable=MERGEABLE, an allowed merge button, a ruleset that lacks required status checks, or successful local tests. Those are not substitutes for completed successful GitHub CI.

Use an explicit merge command only after those checks pass. Do not include --auto:

gh pr merge <number> \
  --repo NVIDIA/TensorRT-Model-Connect \
  --squash \
  --delete-branch \
  --subject "<reviewed squash title>" \
  --body "<reviewed squash body>"

After merging, verify the PR state is MERGED and report the merge commit. If a linked issue was expected to close, verify the issue state separately.

Rebase

Do not overwrite a dirty user checkout. For a resolved same-repository source branch, prefer a temporary worktree:

git fetch github main <branch>
git worktree add <temporary-path> -b <temporary-local-branch> github/<branch>

Inside it, rebase onto the freshly fetched base:

git rebase github/main

For mechanical conflicts, read both sides, resolve, git add, and continue. For semantic conflicts, stop and report exactly which files and decisions need a human. Run focused validation and verify that the rebased diff still matches the PR intent.

Before a history rewrite, record the exact remote branch SHA. Push only the resolved source branch with an explicit lease:

git push github HEAD:<branch> \
  --force-with-lease=<branch>:<previous-remote-sha>

For an additive fix, use a normal push. Re-read headRefOid after every push and restart CI evaluation.

Diagnose Failed Checks

Use Source Actions logs only for the retained Source workflows: Internal CI Bridge and Pages. List recent Source bridge runs:

gh run list \
  --repo NVIDIA/TensorRT-Model-Connect \
  --workflow internal-ci-bridge.yml \
  --limit 20

Inspect failed retained-Source logs:

gh run view <run-id> --repo NVIDIA/TensorRT-Model-Connect --log-failed

For a failed TRTMC Internal CI / Automated premerge gate status, inspect Internal CI only when authorized. If private evidence is unavailable, report the exact head, sanitized status, and a human blocker; do not guess or disclose private URLs.

Download Internal artifacts only when authorized and when a private job points to structured outputs:

mkdir -p .ci_artifacts/pr<number>
gh run download <run-id> \
  --repo <internal-owner>/<internal-ci-repository> \
  --dir .ci_artifacts/pr<number>

Keep downloaded Internal evidence local and private. Never attach it to the Source PR or a Source workflow. When E2E artifacts exist, inspect result.json fields such as status, failure_type, stage statuses, stage messages, metric values, and thresholds.

Classify failures:

DiagnosisAction
Build or test error caused by PR codeFix the PR code
Failure caused by rebase driftAdapt the PR to current main
E2E failure also present on current mainReport as pre-existing; do not mask it
Infrastructure or unavailable hardwareReport with run/job links
Threshold-only disagreement near baselineCompare against main before changing thresholds

Fix

  • Read the PR diff first with git diff github/main...HEAD.
  • Make the smallest code or test change that addresses the failure.
  • Run the most relevant local verification available.
  • Use $write-git-messages for a clear commit message that complies with the repository ruleset.
  • Push back to the same PR branch.
  • Add a PR comment only when it communicates root cause, validation, or a blocker not already visible from commits.

Report

Always include a complete cycle summary:

PR     Action      Branch                         Details
#123   OK          feature-a                      Checks green
#124   REBASED     feature-b                      Rebased onto github/main and pushed
#125   FIXED       feature-c                      Fixed compile error; pytest ... passed
#126   BLOCKED     feature-d                      Semantic conflict in src/runtime/...

For each PR include its URL, base, source repository/branch, exact head SHA, current status/check URLs and states, action, validation, mergeability/review state, blockers, residual risk, and whether a branch was pushed or merged. An unchanged pending state is normal during monitoring.

<!-- Collaborative review anchor: batch 2. -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.