Menu

Individual skill

release-readiness-hardening

0upvotes

Audit or harden an existing application's release readiness, including deploy prerequisites, minimal release gates, rollback, production-shaped smoke checks, and post-deploy verification. Use only when the user explicitly asks for a release-readiness review, deploy or release gates, rollback rehearsal, production verification, or hardening of a deployment path. Do not trigger merely because work will eventually be merged, shipped, deployed, or touches CI/CD.

release-readiness-hardening/SKILL.md

Read pinned source

Source commit 1acf58f08cca24b764a4352a6c30fed1f7fb9fb6

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 11, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
198
Repository last updated
Nov 9, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Release Readiness Hardening

Use this skill to answer: can this ship safely, and what is the smallest sufficient proof? Treat every gate, identity, queue, receipt, and manual step as operational cost.

## Counterweight: simplify before adding

- Start from current callers, stored data, provider facts, and failure history. Do not preserve machinery merely because it exists.
- Inventory existing controls before proposing new ones. Delete, combine, or narrow controls that duplicate the same authority or fact.
- Add a gate only for a concrete material failure mode not already covered. Record why a cheaper existing signal is insufficient.
- When one trusted system builds, deploys, and observes production end to end, do not invent signatures, admission ceremonies, or proof handoffs between its internal stages.
- Prefer authoritative external facts—exact source, immutable provider version, traffic, health, and rollback target—over duplicated internal evidence.
- Do not create bookkeeping PRs, proof PRs, smoke commits, or known-impossible release attempts solely to exercise release machinery.
- For self-hosting CI/CD changes, validate with the currently trusted base configuration, then reload the merged configuration after merge. Do not require a new workflow to authorize the change that introduces it.
- A typed pre-mutation failure is a valid safe outcome. Stop, preserve the failure and unchanged production state, and identify the smallest real fix; do not manufacture source changes to obtain different evidence.
Back to top