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 merges via `gh pr merge --squash`, deferring to native branch protection with the merging account configured as a ruleset `bypass_actor`) 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. `deploy.md` now defers to this natively rather than bypassing it outright, so it's a live merge-gate for the deploy pipeline