git:20260915.5ca5c10 to git:20260923.d4825ad

32 added, 24 removed. Audit A to A.

---

name: babysit

description: Babysit a pull request through the NorbiAI review loop until no valid issue remains. Fix valid findings, rebut false positives with checkable evidence, and re-request review. Use when asked to babysit a PR, handle NorbiAI comments, or clear the NorbiAI review gate.

---

# Babysit

Drive one pull request through repeated NorbiAI reviews until no valid issue

remains. Fix each valid finding. Rebut each false positive with evidence.

Ask for a new review after each round.

Use this skill only for the NorbiAI review on the current pull request.

Do not use it for human reviews or for other bots.

## Before you start

+ Do this once, not in each loop.

- Read `AGENTS.md` and each nested `AGENTS.md` for a directory you change.

- Read `.github/norbiai-review-prompt.md`. It defines `[NEW]`, `[REMAINS]`,

`[RESOLVED]`, `[WITHDRAWN]` and what counts as a valid rebuttal.

- Find the pull request number and the branch. Check `git status`.

Commit or stash unrelated work first.

- Confirm `gh` can read the pull request. You need the latest review

comment and the `NorbiAI review` commit status on the head SHA.

## Step 1 — Read the latest review

- 1. Load PR comments with `gh api`. Find the newest comment from

- `github-actions[bot]` with `` in the body.

+ 1. Load only the newest comment from `github-actions[bot]` with

+ `` in the body. Filter with `gh api --jq`; do not

+ print all PR comments.

2. Record `Reviewed commit` from the comment. Compare it with the head SHA.

Stop when the review is stale. Wait for a fresh review instead.

3. Read `## Findings`, `## Resolved Since Previous Review`, and

`## Withdrawn Findings` as one set. Note the `[NEW]` and `[REMAINS]`

tags and each `P0` to `P3` priority.

4. Read the `NorbiAI review` commit status on the head SHA. The gate

blocks merge on unresolved `P0` and `P1` findings.

Do not act on an old review. Do not edit the review comment.

## Step 2 — Triage each finding

Check each finding against the full current diff and the surrounding code.

Prove the failure mode. Never trust the title alone.

Mark a finding as **valid** when it shows all of the following:

- It points to changed code or a direct effect of changed code.

- It names a concrete failure, cost, or broken contract. Examples:

correctness, security, data loss, concurrency, broken contract, concrete

performance regression, dead code to delete, code to reuse.

- It proposes the smallest fix.

Mark a finding as **not valid** when one of the following holds:

- The guard, check, or contract it asks for already exists. Name the

file and line.

- It reports a style choice, a naming opinion, or a vague concern

with no failure mode.

- It reports a speculative edge case with no path to reach it.

- It asks for a test with no concrete regression that test would catch.

- It asks for work outside the stated problem of the pull request.

Record the verdict in a table before you change code:

| --- | --- | --- | --- |

Fix only valid findings. Rebut the rest. Never fix a finding you

cannot reproduce in order to turn the gate green.

## Step 3 — Fix each valid finding

1. Apply the smallest change that removes the problem. Prefer delete

and reuse over new code.

2. Obey the non-negotiable rules in `AGENTS.md`: keep migrations

irreversible-safe, keep released Team API meaning unchanged, keep the

renderer-to-main trust boundary, redact secrets, keep the license.

- 3. Run the narrowest relevant test file first. Then run `bun run lint`

- and `bun run typecheck`. Also run `bun run check:ui` for changes

- in `src/renderer`. Fix what your change broke. Rerun the checks.

+ 3. Run the narrowest relevant test file and

+ `biome check --write --max-diagnostics=none <changed paths>`, as

+ `AGENTS.md` says. Leave broad checks to CI.

4. Commit the fixes on the pull request branch.

Do not weaken a test to satisfy a finding. Do not widen a type to

`any` or `unknown` to bypass a checker. Do not change

`.github/norbiai-review-prompt.md` or `.github/workflows/norbiai-review.yml`

to pass the review.

## Step 4 — Rebut each false positive

The reviewer withdraws a finding only for a concrete, checkable reason.

Assertion without evidence does not work. A promise to fix it later

does not work. Disagreement about priority does not work.

- Write one pull request comment that covers all rebuttals. For each

- finding give:

+ Write one short comment for all rebuttals. Each response goes into the

+ next review prompt, so every word costs tokens. Write one line for each

+ finding, in ASD-STE100 Simplified Technical English:

- - The finding title, priority, and `path:line`.

- - The concrete reason it is wrong: the guard it misses, the line that

- already handles it, or the contract it misreads.

- - The place where you verified the reason: file, line, and current head SHA.

+ ```

+ P1 Short title: wrong, <guard or contract> at `path:line`.

+ ```

- Include `/norbiai review` in the same comment. That phrase asks for a

- recheck. Without it the reviewer never sees the rebuttal.

+ Give only the reason and the line that proves it. No greeting, no fixes

+ summary, no head SHA, no restated finding. The reviewer reads the fixes in

+ the diff.

Only a comment from someone who can merge counts as a rebuttal. The

workflow ignores other comments. When you cannot post as such a user,

give the user the exact comment text and wait. Do not post it yourself.

Never forge `` or ``

markers. Never edit another comment.

## Step 5 — Push and ask for a new review

One loop is one push plus one review run:

- 1. Push the branch with the fixes.

- 2. Post the rebuttal comment from Step 4 in the same round. The comment

- must contain the fixes summary, each rebuttal, and `/norbiai review`.

- As an alternative, apply the `norbiai` label. The label path also

- asks for a review.

- 3. Wait for the new `` comment and the new

- `NorbiAI review` status on the new head SHA. Poll with `gh api`.

- Do not start the next triage on the old SHA.

+ Ask for one review only. Each extra request is a full review run.

+ 1. With fixes to push: post the rebuttal comment first, without

+ `/norbiai review`. Then push. The review for the push reads every

+ comment posted since the last review.

+ 2. With no fixes to push: add `/norbiai review` to the rebuttal comment.

+ That phrase asks for a recheck.

+ 3. Do not also apply the `norbiai` label. The label asks for a full

+ review of the whole PR.

+ 4. Wait for the new `` comment and the new

+ `NorbiAI review` status on the new head SHA. Poll with `gh api` at

+ most once each 2 minutes; a review takes 3 to 15 minutes. Do not start

+ the next triage on the old SHA.

When the push itself triggers a review with no comment from you, still

wait for that review before you continue.

## Step 6 — Loop until clean, then stop

Start Step 1 again on the new review. Carry the ledger forward:

- A `[RESOLVED]` finding needs no more work.

- A `[WITHDRAWN]` finding must not return. When code added since

reintroduces the same problem for a new reason, treat it as new.

- A `[REMAINS]` finding needs a fix or a stronger rebuttal. Say which

part of your last response the reviewer could not verify.

Stop when both hold:

- `## Findings` says `No actionable findings.` or holds only findings

you proved not valid and the reviewer withdrew.

- The `NorbiAI review` status on the head SHA is success.

Also stop and ask the user when the same finding returns twice with no

progress, when a `P0` finding is genuinely valid but the fix needs a

product decision, or when the review reports malformed output or failure.

Report the loop count, the fixes, the rebuttals, and the final status.

## Report format

- After each loop, report:

+ Keep the report short. After each loop, report:

| Finding | Verdict | Action |

| --- | --- | --- |

| Short title - `path:line` | fix / rebut | Commit or rebuttal line |

- Then state the head SHA, the checks you ran, how you asked for the

- next review, and what the next loop must check.

+ Then state the head SHA and the checks you ran, in one line each.