GitHub Branch Protection and Merge Rules Review
Review your GitHub branch protection settings against good practice and get a gap table with the safest order to tighten rules.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Act as a careful engineering lead reviewing the rules on our own GitHub repository [REPO_NAME]. I will paste or describe the current branch protection or ruleset settings for [PROTECTED_BRANCHES]: required reviews [REQUIRED_REVIEWS], required status checks [REQUIRED_CHECKS], whether force pushes and deletions are blocked, whether admins can bypass, and how merges are done (merge commit, squash or rebase) [MERGE_STYLE]. Team size is [TEAM_SIZE] and we deploy [DEPLOY_PATTERN]. Return: 1) A table with the columns Setting, Current value, Risk if left as is, Suggested value and Effort (low, medium, high). 2) A score from 1 to 5 for Review rigor, Test gating, Protection from accidents, and Developer friction, with a sentence on each. 3) A list of rules that could slow the team without adding safety. 4) A rollout order that avoids blocking work on day one, for example start by requiring checks and only later raise the reviewer count. 5) Three questions I should ask my team before changing anything. Work only from the settings I paste. GitHub setting names, ruleset features and plan limits change, so mark each specific setting or menu path [VERIFY] against our current GitHub plan. This is about the process for our own repository; do not suggest bypassing anyone's controls, and do not make changes automatically. Recommend a trial on a non-critical repository first.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.
See an example result (fictional data)
| Setting | Current | Risk | Suggested | Effort | | Required reviews | 0 on main | Unreviewed code can merge | 1 approval | Low | | Required checks | none | Broken builds can merge | Require unit tests job | Low | | Force pushes | allowed | History can be rewritten | Block | Low | | Admin bypass | on | Rules skipped under pressure | Keep, but log use [VERIFY] | Medium | Scores (invented): Review rigor 1, Test gating 1, Protection from accidents 2, Developer friction 5. Rollout: week 1 required checks and block force pushes; week 3 one approval. Ask the team: who covers reviews when someone is away?
Illustrative only, made-up data. Your results will differ and must be reviewed.