How it works
01 /
Require evidence from the expected App
The managed ruleset requires the Codex review gate and pins the check to the integration. Optional title and commit-message policies add their own App checks when configured. Publishing a similarly named commit status does not establish the same App-owned evidence.
02 /
Keep the base current
Requiring the PR branch to be up to date prevents it from merging against default-branch policy changes it has not incorporated. The ruleset requires pull requests, adds no extra approval count and allows initial branch creation. It has no bypass actors, including administrators or the automation App itself.
03 /
Reconcile as the repository changes
Default-branch pushes reconcile the managed ruleset and queue open PRs. Periodic reconciliation repairs drift and refreshes repository state. Configuration preview checks remain informational rather than silently becoming a mandatory rule.
A concrete example
Workflow example
Default branch ruleset
Required: codex/review-gate from the toolkit App
Optional: configured title and commit-message checks
Required: strict base freshness
Bypass actors: noneAvailability and limits
Current limits
GitHub plan capabilities constrain metadata rules. When commit-message metadata enforcement is unavailable, the toolkit records that state and explains the remaining Check Run enforcement. Ruleset reconciliation needs the App’s accepted repository permissions and does not make unrelated rules disappear.
Common questions
Can the merge command bypass its own ruleset?
No. Its installation token is subject to the ruleset, which declares no bypass actor.
Is the configuration preview check required automatically?
No. ci-toolkit/config is informational and is not added to this managed ruleset.
Runnerless / early access
Interested in this workflow?
Get early access ↗Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.