Maintain Github Repository

Maintain GitHub Repository

Purpose

Audit or align server-side GitHub repository settings without mixing those changes into local Git operations or release automation. The default path is a read-only audit. Apply changes only when the user requests mutation.

When To Use

• Use this skill when creating or configuring a GitHub repository.
• Use this skill when the user asks to apply their normal GitHub repository defaults.
• Use this skill when auditing repository features, merge methods, security automation, sign-off requirements, branch protection, or rulesets.
• Use this skill when GitHub settings may have drifted from repo policy.
• Use this skill when a bootstrap or sync workflow reaches the GitHub remote configuration step.
• Do not use this skill for local commits, branches, rebases, merges, pushes, pull-request bodies, review replies, tags, or GitHub release creation.
• Use maintain-project-repo for protected-main releases, publishing, tags, GitHub release objects, release cleanup, and branch accounting.
• Use maintain-project-contributing when the repository's DCO, contributor grant, or sign-off documentation needs to change.

Workflow

1. Resolve the repository:
   • confirm owner/repo, default branch, visibility, and current user permissions
   • verify the target is the repository the user intended
   • read repo-local AGENTS.md, contribution policy, security policy, and release guidance before selecting a baseline
2. Load references/github-repository-settings.md.
3. Audit before mutation:
   • read supported repository settings with gh repo view and gh api
   • inspect branch protection or rulesets separately from general repo settings
   • inspect Dependabot, secret scanning, push protection, private vulnerability reporting, web commit sign-off, and auto-close behavior independently
   • verify required status-check names against actual recent check runs when branch protection depends on CI
4. Classify every relevant setting as:
   • aligned
   • drifted
   • unavailable
   • unknown
   • not applicable
5. Report current values, recommended values, unavailable settings, and exact planned mutations separately.
6. Apply only requested changes:
   • use gh repo edit for supported general toggles
   • use current documented gh api endpoints for security, sign-off, auto-close, branch-protection, and ruleset settings
   • prefer file-backed .github/dependabot.yml, CODEOWNERS, SECURITY.md, workflow, and contribution-policy changes when the behavior is owned by repository files
   • keep visibility changes separately approval-gated
   • preserve documented maintainer direct-push workflows
7. Re-read every changed setting and report the verified result.

Inputs

• repository: optional owner/repo; default to the current checkout's GitHub remote only when unambiguous
• mode: audit or apply
• requested_changes: optional explicit settings changes
• baseline: repo-local policy or the recommended baseline reference
• Defaults:
  • mode=audit
  • visibility remains unchanged
  • no settings are mutated without an apply request

Output

• Repository: exact owner/repo, visibility, and default branch
• Current Settings: observed values
• Recommended Settings: repo-policy or fallback baseline
• Unavailable Settings: plan, visibility, permission, or API limitations
• Planned Changes: exact mutations, empty in audit-only mode
• Applied Changes: mutation results, apply mode only
• Verification: post-mutation values or audit evidence
• Follow-Up: file-backed policy, DCO check, CI check-name, release, or contributor-doc work that belongs to another skill

Guards

• Never infer or bundle a repository visibility change.
• Never weaken security settings just to make an audit pass.
• Never require approving reviews when the repo has no independent reviewer unless the user explicitly wants that policy.
• Never block a documented maintainer direct-push workflow accidentally.
• Never guess a required status-check context from a workflow display name.
• Do not treat GitHub web sign-off as command-line DCO enforcement.
• Apply all available requested settings before reporting settings that GitHub cannot expose for the current plan or visibility.
• Keep credentials, tokens, and private vulnerability details out of reports.

Trigger Evaluation

Use references/trigger-eval.md to verify that settings and policy requests trigger this skill while ordinary Git and release requests route elsewhere.

References

• references/github-repository-settings.md
• references/trigger-eval.md