Babysitting PRs

Drive a branch or GitHub pull request to the end state the user requested: published, updated, merge-ready, or merged.

Authorization And Scope

Inspecting local or PR state is read-only. A request to publish, update, address feedback, prepare, land, or merge authorizes the corresponding branch and PR writes; preserve unrelated work and avoid rewriting remote history unless explicitly authorized.
Merge only when the user explicitly asks to merge, land, ship, queue, or get the PR merged. “Prepare to land,” “babysit,” “make mergeable,” and “ready for review” mean merge-ready only. Ambiguous follow-ups such as “looks good” do not grant new merge permission.
Do not introduce GitHub Codex review. Continue it only when the PR already has Codex review activity or the user explicitly asks for it.

Use writing-pr-descriptions before creating a PR and after material changes to an existing PR.
Use auto-review when the user asks for it or the diff is materially risky: behavior, public contracts, data, security, concurrency, migrations, or cross-cutting structure. For small docs, metadata, configuration, or mechanical changes, use focused inspection and risk-matched validation instead of a mandatory full review loop.
Use handling-codex-reviews only for an already-active or explicitly requested Codex loop.

Use a bounded loop, normally no more than three fix cycles. Batch related fixes before pushing.