What this prompt does
This prompt makes the model act as a senior platform engineer and return the exact CODEOWNERS file, branch-protection JSON, and gh CLI commands to apply them, not vague guidance. Four placeholders shape the output: [repo_name] (the repository), [team_size] (the number of engineers), [reviewers] (required approvals per PR), and [ownership] (the map of who owns which paths).
The structure works because repo governance should be reproducible, not click-ops. By asking for a branch-protection ruleset on main (required status checks, required approving reviews, dismiss stale approvals, require conversation resolution), linear history with force-push and deletion blocks, a complete CODEOWNERS file from [ownership] with glob precedence explained, gh commands to apply it all, and a short hotfix bypass policy, the prompt produces config you can commit and re-apply. Deciding the bypass before enabling signed commits prevents locking out your own emergency fix. Sizing [reviewers] against [team_size] keeps the review requirement achievable, and writing [ownership] as concrete paths means reviews route to the right team automatically instead of landing on whoever happens to be free.
When to use it
- You are locking down main on
[repo_name]and want it reproducible rather than configured by hand. - You want required reviews, status checks, and stale-approval dismissal set as a ruleset.
- You need a CODEOWNERS file built from a specific
[ownership]map with glob precedence explained. - You want linear history with force-push and deletion blocked.
- You are weighing signed-commit enforcement and want the tradeoffs spelled out.
- You need a bypass policy for hotfixes and clarity on who can use it.
Example output
Expect fenced blocks ready to commit: the complete CODEOWNERS file implementing [ownership] with glob precedence explained, the branch-protection ruleset JSON for main (required checks, [reviewers] approving reviews, dismiss stale approvals, require conversation resolution, linear history, force-push and deletion blocks, optional signed commits with tradeoffs), and the gh api/gh CLI commands to apply the protection reproducibly. A short bypass policy for hotfixes and who can use it closes it out.
Pro tips
- Write
[ownership]as concrete path-to-team mappings (e.g. backend owns/api, frontend owns/web) so CODEOWNERS routes reviews automatically. - Set
[reviewers]to match[team_size]; requiring two approvals on a three-person team will stall every PR. - Decide your hotfix bypass before turning signed commits on, or you risk blocking your own emergency fix.
- Apply the rules with the generated
ghcommands rather than the UI so the setup is reproducible and reviewable. - Have the model explain CODEOWNERS glob precedence — later matching patterns win, and getting that wrong sends reviews to the wrong team.
- Turn on require-conversation-resolution and dismiss-stale-approvals together; the first stops unresolved threads merging, the second forces re-review after new pushes.
- Document the hotfix bypass policy in the repo so the team knows who can use it and when, rather than discovering the rule during an incident.
