docs(agents): CodeRabbit does not auto-review this repo, and its check never resolves

[doublegate]

Found while working #411, and it has been true since #316 landed.

CodeRabbit does not auto-review this repository

Its own comment says why:

This repository does not receive automatic reviews because it has fewer than 10 stars.

The configuration is loaded and correct — the same comment reports Path: .coderabbit.yaml, Review profile: ASSERTIVE, Plan: Pro Plus. Nothing about #316's config work is wrong. Only the automatic trigger is absent.

Two consequences, both operated wrongly until now

The ceremony silently covers two bots, not three. AGENTS.md credits CodeRabbit with catching a critical fast-forward defect (#358) and a use-after-free in the v2.3.5 libretro controller tables — and none of that arrives unless a review is requested. A PR described as "reviewed by all three bots" has in fact been reviewed by Copilot and Antigravity. @coderabbitai review requests one; I have posted it on all five currently-open PRs.

Waiting for zero pending checks never terminates. The CodeRabbit context sits with a null status and a null conclusion indefinitely. A healthy PR here reads as ~27 checks with exactly one permanently pending, which is indistinguishable from a build still running if you gate on "nothing pending".

The merge criterion is therefore CI success = SUCCESS with every other check complete. Not "nothing pending", and not a bare check count either — a CONFLICTING PR also shows a short list, because GitHub cannot build a merge ref and CI never runs at all.

Verification

Docs-only, one line added to AGENTS.md. The quoted reason, the profile, and the plan are read from the bot's comment on #411; the null status is read from the check rollup on #410, a PR that has already merged.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e6c3d560-c71d-4c37-89a4-84dffea8b318

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Updates contributor/agent guidance to document that CodeRabbit does not auto-review this repository (and that its GitHub status context can remain pending), so reviewers don’t mistakenly wait for “no pending checks” or assume a CodeRabbit review happened without explicitly requesting it.

Changes:

• Document that CodeRabbit auto-review is not enabled for this repo and must be explicitly requested when desired.
• Clarify the operational consequence for merge gating: use CI success plus completion of other checks rather than waiting for zero pending checks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[doublegate]

Good suggestion, and it sent me to check the actual configuration rather than assume it — which is the right instinct. It turns out not to apply, and both reasons are now in the entry so the next reader does not re-propose it.

There is nothing to remove from branch protection. main's ruleset requires exactly one status context:

$ gh api repos/doublegate/RustyNES/rules/branches/main --jq '[.[]|select(.type=="required_status_checks")|.parameters.required_status_checks[].context]'
["CI success"]

So the pending CodeRabbit context is not required and blocks nothing. Nothing is stuck; the only cost is that "wait for zero pending" is an unreachable criterion for a human or an agent reading the rollup — which is what the entry exists to say.

Disabling its status reporting would cost the one case where it matters. CodeRabbit can be triggered manually, and when it is, the check is the signal that a review ran. Suppressing the context to make idle PRs look tidier would remove the indicator on precisely the PRs where a review was requested.

I have also added the thing this session found the hard way: CodeRabbit rate-limits manual triggers per developer. I posted @coderabbitai review on five PRs and got "you've reached your PR review limit" on the later ones — so a batch trigger can produce no reviews at all while looking like it worked. That is worth knowing before relying on a requested review.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@doublegate Thanks for verifying the ruleset and the manual-trigger behavior.

The CodeRabbit context is not required by main, so it does not block merges. Keeping it is correct because it signals that a manually requested review ran. The updated entry also correctly documents that manual review requests can be rate-limited per developer.

---

✏️ Learnings added

Learnt from: doublegate
URL: https://github.com/doublegate/RustyNES/pull/416

Timestamp: 2026-08-19T21:55:10.749Z
Learning: In the RustyNES repository, the `main` branch ruleset requires only the `CI success` status context. The permanently pending `CodeRabbit` context is not required and does not block merging. Do not recommend removing it from branch protection.

---

Learnt from: doublegate
URL: https://github.com/doublegate/RustyNES/pull/416

Timestamp: 2026-08-19T21:55:10.749Z
Learning: In the RustyNES repository, CodeRabbit does not automatically review pull requests. A manually requested CodeRabbit review produces the `CodeRabbit` status context, which is the evidence that the review ran. Manual review requests are rate-limited per developer, so batch requests can leave later pull requests without a review.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

_{You are interacting with an AI system.}

[doublegate]

Good catch, and it is this PR doing to itself the thing it documents. Fixed at the source rather than by merging the two bullets.

The bullet directly above has said since #316 that CodeRabbit is a "3rd automated PR review bot" whose ceremony "applies before any merge". The new bullet says it does not auto-review and that the ceremony covers two bots. Left adjacent, a reader arriving at the first gets the false claim and the correction only if they keep going — prose asserting a behaviour the system does not have, reproduced while documenting an instance of it.

The #316 bullet now says CodeRabbit is configured as a third bot, that the ceremony applies to its threads, and that it does not review automatically, pointing forward for the detail. It also records what the old wording cost: "automated" plus "applies before any merge" read as a promise that its findings were arriving, and they were not.

Kept as two bullets rather than one because they answer different questions — what is configured and what actually happens — and the second is long enough that folding it in would bury the trigger instruction. The contradiction is gone, which was the real problem.

On the verbosity nitpick: same answer as the other PRs — AGENTS.md is this project's standing-rules file and its explicit rule is to explain the why. The three merge conditions are stated because gating on any one of them alone is what produced two of this session's wrong calls.

[github-actions]

Antigravity review (Gemini via Ultra)

This PR updates the agent documentation to clarify that CodeRabbit PR reviews must be triggered manually and provides instructions for handling its permanently pending CI check.

Blocking issues

None found.

Suggestions

• AGENTS.md (line 224): The addition ("This one said 'automated'... from chore(deps): master version-bump consolidation (closes #313, #314, #315) #316 until v2.3.9, which read as a promise...") introduces conversational history rather than rules. Even though it matches the verbose style of surrounding bullets, it violates the "smallest correct change" guideline. Stick to the facts of the current configuration.
• AGENTS.md (line 225): The forward-reference in "First, the ceremony below silently covers two bots, not three" hurts readability by requiring the reader to scan ahead to the next bullet point. Explicitly name the "review body checking ceremony" rather than pointing "below".

Nitpicks

• The change is a trivial documentation update, but the new bullet is exceptionally dense.
• AGENTS.md (line 225): "operated wrongly" is awkward; consider "mishandled" or "handled incorrectly".

_{Automated first-pass review by agy on a self-hosted runner -- not a human review.}