repo-configlisted

# repo-config skill ## Purpose Capture the repository-level configuration that turns CI into an actual gate. The audit's verification commands are only meaningful if `main` cannot be merged unless they pass. ## When invoked - By `test-design` (Phase 2) — emits the **Repo Configuration** section of the blueprint - By `test-roadmap` (Phase 4) — applies the **pairing rule** (every CI-workflow task gets a paired branch-protection task) - By `test-fix` (Phase 5) — the task's `acceptanceCriteria` array is the task-store equivalent of a Closing Checklist ## The repo-config plan A complete repo-config plan covers four concerns: ### 1. Branch protection For each protected branch (default: `main`): This is the standard recommendation for every shipwright repo — one flat default, not a choice between options. Shipwright repos are moving toward `shipwright-deploy` (agent self-merges via `--admin`) across the board, so recommend the settings below regardless of where a given repo currently is in that rollout. - **Required PR** — no direct pushes. - **Required status checks** — every layer-relevant CI job from `test.yml` (lint, per-service unit, per-service integration, smoke, E2E). This is the real gate: CI must be green on the branch that lands. It's still a useful signal even though `deploy.md` merges with `--admin` — it gates any merge attempt that doesn't go through `deploy.md` (e.g. a human merging via the GitHub UI). - **Require conversation resolution before merging** — *