Adopt layered review in a repository

Goal: most changes get reviewed by machines, human time goes where the risk is, and reverts and incidents don't go up. Start strict; loosen only with evidence.

Templates are in this skill's templates/ directory.

Step 1 — Scorecard (read-only)

Inspect the repo and, if gh is authenticated, the GitHub settings. For each row record present / partial / missing and the evidence (file path, setting value, or "could not check"). Never guess a setting you could not read.

Useful read-only commands:

gh api repos/{owner}/{repo}/rules/branches/{default_branch}        # effective rulesets: reviews, threads, merge queue, checks
gh api repos/{owner}/{repo}/branches/{default_branch}/protection   # classic protection (needs admin; 404 = none)
gh api repos/{owner}/{repo}/actions/permissions/workflow           # can_approve_pull_request_reviews should be false

Show the scorecard as a table, then the three gaps that would cut the most risk per hour of work. Typical order: required CI and a PR template, then AI + security review on one repo, then risk tiers with CODEOWNERS and branch protection.

Step 2 — Propose (dry run)

List every file you would create or change, with its full content or a diff. Fill templates with real values from this repo: actual check commands, actual sensitive directories (search for paths containing auth, billing, payment, install, updater, release, migration, deploy, secret), actual owners if CODEOWNERS or git history shows them. Leave {placeholders} only where you cannot know the value, and say so.

Rules:

• Never overwrite an existing file. If it exists, propose a merge as a diff.
• Keep actions pinned to commit SHAs with the version in a comment, and permissions minimal.
• Do not put PR titles, bodies or branch names into run: scripts (script injection).

Step 3 — Apply on confirmation

Write only the files the user approved. Then print, but do not run, the settings changes:

• Require the CI checks, the review workflow and the security workflow on the default branch.
• Require conversation resolution before merge.
• Require at least 1 approving review and code-owner review; dismiss stale approvals on new commits (an approval covers one commit).
• Turn off "Allow GitHub Actions to create and approve pull requests" — a bot approval never fills a human slot.
• Enable the merge queue if the repo merges often enough for main to break from combinations.

Change GitHub settings only if the user explicitly asks you to run those commands.

Step 4 — Roll out

Recommend: one repo first; tune REVIEW.md for a few weeks by moving repeated review comments into it (or into a lint rule); then widen. Write the risk tiers down, set from the change, not the author. Allow zero-human merges for Low only after the repo has a flag/revert path, a reviewer eval set, and a few weeks of revert and incident rates that did not rise. Measure human time (approvals per PR, human comments, time a PR waits on a person) with revert and incident rates as the guardrail.