GitHub Repo Standardizer

Detect a repository's current state, then polish its surface: issue forms, PR template, label taxonomy, CI, CODEOWNERS, rulesets, docs. Works on repo metadata and config files only — code logic is never touched. Idempotent — safe to re-run; fills gaps and reconciles drift without duplicating or clobbering.

When to use

• User says "standardize / tidy up / professionalize this repo"
• A new repo was just created and needs templates, labels, CI, and rules from day one
• A repo looks bare: no templates, no labels, no CI, no branch protection

Preflight (mandatory, in order)

Requires: gh CLI (authenticated), git, jq, python3 — verify they exist before starting (which gh git jq python3).

1. Authenticate — check gh login first

gh auth status 2>/dev/null || echo "NOT_LOGGED_IN"

• Logged in → continue; print gh api user -q .login so the user knows which account will act.
• Not logged in → STOP. Tell the user (do not guess):
  1. Run gh auth login (web/device flow), or
  2. Export a token: export GH_TOKEN=ghp_xxx — needs repo, workflow (for CI files) and, for org repos, admin:org (or admin:repo_hook / org membership admin) scopes.
  • Never paste tokens into chat, logs, or files. If the user pastes a token in chat, advise them to revoke it and re-issue.
  • If gh auth login is impossible in this environment (headless), suggest gh auth login --with-token reading from a file the user created.

Verify the acting account can write to the target:

# user repos: no extra check needed beyond token scopes
# org repos: must be a member/admin of the org
gh api "orgs/ORG/memberships/$(gh api user -q .login)" -q .role 2>/dev/null || echo "NO_ORG_ACCESS"

• admin/member → OK. 404 → stop and ask the user to add the account to the org first.

2. Detect repository type

gh repo view OWNER/REPO --json name,owner,visibility,defaultBranchRef,isArchived,isFork \
  -q '{name:.name, ownerType:.owner.type, visibility:.visibility, defaultBranch:.defaultBranchRef.name, archived:.isArchived, fork:.isFork}'

If the repo was not explicitly named by the user, confirm before touching an org or private repository.

3. Audit current state

gh label list --repo OWNER/REPO --limit 200
gh api repos/OWNER/REPO/contents/.github -q '.[].path' 2>/dev/null || echo "no .github dir"
gh api repos/OWNER/REPO/contents/.github/workflows -q '.[].name' 2>/dev/null || echo "no workflows"
gh api repos/OWNER/REPO/rulesets -q '.[] | {name:.name, enforcement:.enforcement}' 2>/dev/null || echo "no rulesets"
gh api repos/OWNER/REPO/branches -q '.[].name' 2>/dev/null
for f in README.md CONTRIBUTING.md SECURITY.md LICENSE .gitignore; do
  gh api "repos/OWNER/REPO/contents/$f" -q .name 2>/dev/null || echo "missing: $f"
done

4. Detect test framework (for CI module)

Check for these signals (first match wins):

gh api repos/OWNER/REPO/contents/package.json -q .name 2>/dev/null   # node → templates/ci-node.yml
gh api repos/OWNER/REPO/contents/pyproject.toml -q .name 2>/dev/null # python → templates/ci-python.yml
gh api repos/OWNER/REPO/contents/go.mod -q .name 2>/dev/null         # go → templates/ci-go.yml
gh api repos/OWNER/REPO/contents/Cargo.toml -q .name 2>/dev/null     # rust → templates/ci-rust.yml

No signal → propose the generic CI (or ask the user whether CI is wanted at all).

5. Ask about language (before planning)

• Ask the user which language CONTRIBUTING.md and the PR template should be written in (default: English, or the project's primary language for local projects). Translate the templates accordingly when generating — never assume a language.
• (README languages are asked separately in Module F.)

6. Ask about automation (decides the Governance labels)

Ask the user whether the repo has any automation bots or AI writers running on it — e.g. dependabot, a Stale bot, ClawSweeper, or an AI coding agent that auto-files PRs / auto-fixes issues.

…