Repo Secure

---
name: repo-secure
description: Audit and enable a GitHub repository's own recommended security settings, confirming with the maintainer which ones actually apply before turning anything on. Use when the user wants a repo hardened, asks to enable secret scanning or branch protection, wants a SECURITY.md written, or references GitHub's maintainer security checklist.
---

# Repo Secure

A repository's security posture is not one setting, it is a system of defaults: who can push, what can merge, which secrets get blocked before they land, how dependencies get flagged, and how vulnerable code gets surfaced before it becomes production risk. This skill's defining constraint, grounded in GitHub's own maintainer security guidance (the six settings every maintainer is told to enable): configuration happens one repository at a time, and never blanket, since a private personal script repo and a public library with external contributors do not need the same posture.

This skill is scoped to the repository's own configuration surface. It is not `secure-coding` (the code inside the repo, mapped to OWASP) and not `dependency-upgrade-management` (the cadence at which dependencies get upgraded once flagged); both are cross-referenced here rather than repeated.

## Phase 1: Inventory what is already on

Before changing anything, check the repo's current settings: SECURITY.md presence, private vulnerability reporting, secret scanning and push protection, Dependabot alerts and dependency review, code scanning, and branch protection rules on the default branch. State what is already enabled and what is not, so the audit has a real starting point instead of assuming a blank slate.

## Phase 2: Confirm which layers genuinely apply

Not every setting belongs on every repo. A private, single-maintainer script repo has little use for external vulnerability disclosure workflows; a public library that other projects depend on needs nearly all of them. Ask the user explicitly which of the following genuinely apply before proposing any of them. The repo's actual visibility and audience should inform the question, but must not substitute for asking it:

- **SECURITY.md and private vulnerability reporting**: how a researcher reports a vulnerability safely, without opening a public issue.
- **Secret scanning and push protection**: catches credentials before they land in history, blocks the push rather than the after-the-fact cleanup.
- **Dependabot alerts and dependency review**: flags vulnerable dependencies; see `dependency-upgrade-management` for what happens once one is flagged.
- **Code scanning**: CodeQL or an equivalent, run in CI so a vulnerability surfaces before merge, not after. Before proposing it, check whether GitHub Actions is available, whether a default or advanced CodeQL setup already exists, what runners it requires, and whether the repository's plan and visibility make the feature eligible.
- **Branch protection**: who can push directly to the default branch, what must pass before a merge is allowed.

## Phase 3: Confirm every change, then enable in order

Get explicit user confirmation before enabling any GitHub repository setting, including private vulnerability reporting, secret scanning, push protection, Dependabot, code scanning, and branch protection. Additive changes such as SECURITY.md and alerting or scanning settings can use a lightweight one-line confirmation, but they still remain unchanged until the user says yes. Branch protection deserves a more careful confirmation because it can block a maintainer's existing push habits or an automation's write access; state exactly what it will restrict before applying it.

If the user's request is a pure audit or otherwise read-only, stay read-only: report the inventory and recommendations without enabling a setting or writing SECURITY.md.

## Phase 4: Record what was deliberately skipped

A setting that was considered and not enabled for a real reason (a solo repo with no external contributors does not need private vulnerability reporting yet, for instance) should be recorded as a deliberate decision, not left silently absent. This is what keeps a later audit from re-litigating the same question from scratch.

## Done when

- [ ] The repo's current settings were inventoried before anything was proposed.
- [ ] Each layer's applicability was explicitly confirmed with the user against this specific repo's visibility and audience, not inferred or applied uniformly.
- [ ] Code scanning eligibility and any existing CodeQL setup were checked before code scanning was proposed.
- [ ] Every enabled setting was explicitly confirmed first; branch protection's restrictions received the most scrutiny and were stated plainly.
- [ ] A pure audit or read-only request stayed read-only.
- [ ] Anything deliberately skipped is recorded with its reason, not left unexplained.
- [ ] Generated prose uses commas, colons, periods, or reworded sentences instead of em dashes.