progressive-deliverylisted

# progressive-delivery A risky change ships behind a flag with a kill-switch and an automated metric gate on its rollout. This skill audits those two mechanisms — nothing else. ## Premise A flag that lives forever, a canary with no automated analysis/abort, or a risky flow with no kill-switch is forbidden. Every finding cites the real artifact: the flag key and the file that defines it, the grep that proves it's never referenced (dead) or hardcoded-on (stale), the AnalysisTemplate/Flagger metric block that is present or absent, the two env configs whose flag values diverge. A "flag looks stale" claim without the reference-count grep is not a finding. A "canary has no gate" claim without showing the rollout spec has no analysis step is not a finding. **Boundary (read first — this is not a deploy-strategy skill):** - `@deployment-engineer` owns canary/blue-green as a **deploy STRATEGY** — which one, resource overhead, rollback command. It does not audit whether a flag is orphaned or whether a canary's metric gate is actually wired. - `monitor-deploy` watches **a single deploy's** health window and triggers `/rollback-deploy` on breach. It does not own the flag's whole lifecycle, cross-env flag parity, or the canary's *automated promotion* logic. - **THIS** owns (a) flag lifecycle — stale/orphaned/permanent flags, kill-switch presence, cross-env parity, flag→config coupling; and (b) automated canary ANALYSIS wiring — the AnalysisTemplate/metric gate that promotes or aborts w