agentsclimarketplace

Release readiness

Skill NjoyimPeguy/augments/plugins/augments/skills/release-readiness

Use after integration and before each release promotion verdict—initial canary/stage, expansion, full deployment, publication, or distribution—for services, applications, libraries, packages, CLIs, and artifacts. Skip only work with no releasable or running artifact.From its SKILL.md

Install
npx -y skills add NjoyimPeguy/augments --skill release-readiness

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.6 KB, 895 tokens by cl100k_base, as published. Nobody here has run it

Release Readiness

Merged is not releasable. Judge the exact artifact or artifact set that will be deployed or distributed, under the release gates and recovery conditions that protect its real consumers. This skill decides readiness; it does not perform deployment or publication.

When to use

  • An integrated candidate is approaching an initial or later release promotion.
  • Skip internal work with no release surface. A library/package release is not a skip merely because it has no running production service.

The readiness gate

Use references/release-candidate.md and references/gate-details.md. Every required row is evidenced, not-applicable with rationale, or blocking.

  1. Issue one immutable release-input descriptor. Bind the exact promotion, source/contracts, expected artifacts and gate cells, review/security inputs, source/live queues, deviations/prior-stage inputs, target/consumer state, effect contracts, and approver rule. Keep later attempts and evidence outside it; never expose secret values.
  2. Freeze the artifact set. Through controlled attempts, accept one terminal successful build per required platform/package member from the recorded source; preserve every identity/digest, contents, dependencies, build inputs, provenance, and storage location. Test/promote that set—not a later rebuild.
  3. Verify the artifacts themselves. Install/start/load each required member through representative consumer paths and inspect packaging, configuration, migrations, and generated content. Source-tree green cannot substitute for artifact green.
  4. Run every gate protecting this promotion. Execute its stable expected inventory through verifying-completion; require current differential/ acceptance, static/dynamic safety, security, performance/resource, test-inventory, and platform/build-mode evidence. Reconcile migration shards, source/live changes, and every approved omission within the matrix's lag bound.
  5. Exercise cutover and recovery. Prove snapshot/high-water catch-up, ordering/idempotency, reconciliation/lag, mixed-version data integrity, retained artifacts, rollback/restoration, and RPO/RTO by observed evidence.
  6. Prove target readiness. Verify configuration and secret presence/shape, permissions, capacity, dependency availability, observability, and deploy or publication ordering without exposing secret values.
  7. Bind rollout control. Require telemetry, cohorts, thresholds, soak, abort, rollback, and in-flight behavior from the owning assurance, migration, or release policy. Missing policy blocks; readiness does not invent or lower it. Expansion/full release requires observed prior-stage evidence.
  8. Account for consumers. Verify compatibility and required communication, release/operator notes, and downstream certification. For libraries/packages, install the packed artifact in a clean representative consumer and verify public API/ABI/schema/runtime/metadata obligations.
  9. Disposition every deviation. Record impact, owner, compensating gate, expiry, rollback trigger, and exact approval receipts. Lowering a gate to make the candidate pass creates a new assurance decision; it is not a release fix.
  10. Issue a promotion-bound verdict. Bind status to release-input, artifact-set, terminal-evidence, approval, and freshness identities. Recompute every bound input before a decision/action; any drift invalidates both.

Hard stops

  • Release tests ran on source or a different/incomplete artifact set.
  • Release-input, artifact-set, terminal-evidence, or verdict identity is missing, stale, incomplete, or changed.
  • Any required cell/evidence/change is missing, duplicated, generically skipped/ rejected, unresolved, unowned, misordered, or beyond its bound.
  • Decommission is partial, failed, awaiting/failed validation, or unresolved.
  • Rollback names only source, not a restorable artifact and data/config state.
  • The fixer, builder, or deployer self-accepts an unapproved deviation.
  • “Ready” is treated as authority to deploy or publish.

Common mistakes

  • Rebuilding after tests and assuming the bytes are equivalent.
  • Treating local/pre-merge green as release evidence, or skipping package gates.
  • Calling a bare flag a rollout plan, or an unbounded recovery promise rollback.

What ships with it: 2 files

16.7 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most ship operate skills give in 895 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • verify the frozen artifact set rather than source tree
  • install and test required artifact members through consumer paths
  • run every release gate through verifying-completion
  • exercise cutover and recovery mechanisms
  • verify target readiness including configuration and secrets
  • enforce rollout control policies

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.