agentleFS
imMamdouhaboammarimMamdouhaboammar/get-fable/skills/fable-release/SKILL.md

fable-release

Skill6 starsChanged 3 months agoMITView on GitHub

Audit and certify repository merge and release readiness against required quality gates, clean git working trees, and verified distribution artifacts. Use when preparing a release tag, validating release checklist criteria, publishing npm/PyPI packages, or certifying a branch for merge — even if the user does not explicitly say \"fable-release\" (e.g. \"prepare the release\", \"is this ready to merge\", \"ship to production\", \"publish the package\"). Do NOT use when verification is stale, failing, or missing (use fable-verify first).

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    all canonical version locations/manifests agree.

    line 80
  2. Very specific:

    Do not choose patch/minor/major purely for convenience.

    line 84
  3. Very specific:

    Verify required functional/build/review/security evidence belongs to the candidate SHA/mutation generation.

    line 87
  4. Very specific:

    When available, route branch pushes through the no-mistakes proxy (git push no-mistakes or no-mistakes axi run) to ensure rebase, automated …

    line 88
  5. Very specific:

    Prefer configured trusted publishing/OIDC/host automation over introducing long-lived tokens.

    line 118
  6. Distinctive:

    Do not print/store credentials or weaken security to make a release pass.

    line 120
  7. Very specific:

    If authorization or authentication is absent, stop at READY_NOT_PUBLISHED with exact remaining action.

    line 122
  8. Distinctive:

    After publish, query the external destination rather than trusting the publish command.

    line 125
  9. Very specific:

    Run the user-facing install/invocation path from public distribution.

    line 135
  10. Distinctive:

    Do not collapse these states into "done."

    line 143
  11. Distinctive:

    No credential is committed or logged as release evidence.

    line 158

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fable Release

Prove that the exact commit and artifact users will receive are ready to ship, then distinguish readiness from actual distribution.

Mission

A release is an external state transition. Source tests can be perfect while the package omits files, the tag points at another commit, the registry still serves an old version, or a published artifact cannot start in a clean environment.

This Skill closes that gap by tying release claims to exact version, commit, artifact, workflow, tag, and registry evidence.

Activate When

  • preparing a branch for merge or a version for release;
  • creating/pushing a version tag;
  • publishing npm/package/plugin artifacts;
  • finalizing a GitHub Release;
  • verifying that a distribution channel actually serves the intended version;
  • assessing whether release evidence is current after last-minute changes.

Do Not Activate When

  • implementation is still changing (fable-execute/fable-tdd);
  • functional verification is incomplete (fable-verify);
  • blocking review/security findings remain;
  • the user has not authorized an irreversible publish action. Readiness checks may run; publishing itself requires the applicable authorization.

Release Classification

Release typeExtra concerns
Merge onlybranch/base freshness, required CI, review
Package registrypackage contents, clean install, registry verification
Git tag/GitHub Releasetag→SHA binding, notes/assets, draft/prerelease state
Plugin/marketplacemanifest/version parity, submission/approval state
Migration-bearing releaserollout order, backward compatibility, rollback
Security-sensitive releaseadvisory/secrets/dependency gates, disclosure constraints

Protocol

Stage 1 — Freeze the candidate

Identify the exact candidate:

  • version;
  • commit SHA;
  • target branch/tag;
  • distribution channels;
  • required CI/review/security evidence.

Any source/config/package mutation after this point invalidates relevant release evidence and creates a new candidate.

Stage 2 — Validate version semantics

Check:

  • version does not already exist in target registry/tag namespace;
  • SemVer matches actual compatibility impact;
  • all canonical version locations/manifests agree;
  • changelog/release notes describe user-visible changes accurately;
  • prerelease state is intentional.

Do not choose patch/minor/major purely for convenience.

Stage 3 — Reconfirm fresh quality gates

Verify required functional/build/review/security evidence belongs to the candidate SHA/mutation generation. If evidence was produced before candidate changes, rerun it.

  • When available, route branch pushes through the no-mistakes proxy (git push no-mistakes or no-mistakes axi run) to ensure rebase, automated review, tests, lint, and docs pass before remote merge.

Stage 4 — Inspect the artifact boundary

Build/dry-run the exact artifact and inspect its manifest/content.

Check:

  • required entrypoints/assets/manifests are present and non-empty;
  • secrets, temp files, tests/fixtures/internal holdouts are excluded unless intentionally public;
  • generated files are current;
  • executable permissions/exports/bin paths are correct;
  • dependency/runtime constraints are accurate.

Stage 5 — Clean-environment smoke

Install/use the produced artifact outside the source checkout where feasible.

Prove at least:

  • install succeeds;
  • primary executable/import resolves;
  • version/help/basic smoke works;
  • documented quick-start path is not accidentally relying on repo-local files.

Stage 6 — Verify repository release state

Before publishing:

  • candidate commit is pushed;
  • required CI on the candidate is green;
  • tag does not exist or already points to exactly the intended SHA;
  • release notes/assets target the same tag/SHA;
  • branch is not known-broken relative to base.

Stage 7 — Publish only through an authorized secure path

Prefer configured trusted publishing/OIDC/host automation over introducing long-lived tokens.

Do not print/store credentials or weaken security to make a release pass.

If authorization or authentication is absent, stop at READY_NOT_PUBLISHED with exact remaining action.

Stage 8 — Verify distribution independently

After publish, query the external destination rather than trusting the publish command.

Examples of proof:

  • registry reports expected version/dist metadata;
  • clean install from registry succeeds;
  • Git tag resolves to candidate SHA;
  • GitHub Release is actually public, not draft;
  • marketplace status reflects submitted/published state.

Stage 9 — Post-release smoke and handoff

Run the user-facing install/invocation path from public distribution. Record rollback/deprecation/follow-up issues if observed.

Release Verdicts

  • NOT_READY: required deterministic/review/security/artifact gate fails.
  • READY_NOT_PUBLISHED: candidate is sound but publish is unauthorized/unavailable/not requested.
  • PUBLISHED_UNVERIFIED: publish command/workflow claims success but external distribution has not been independently confirmed.
  • RELEASED: exact candidate is public through intended channels and independently verified.

Do not collapse these states into "done."

Decision Rules

  • A dirty worktree does not automatically fail if dirt is explicitly unrelated and release artifact is from a clean candidate SHA; however uncommitted release changes do fail readiness.
  • Tag exists at different SHA → hard stop; never move/force a release tag casually.
  • Package version already exists in immutable registry → choose a new valid version, do not overwrite.
  • Dry-run contents differ from intended public surface → fix package configuration before tagging/publishing.
  • Local global install works from repo link but clean tarball/registry install fails → NOT_READY.
  • CI green on older commit → stale release evidence.
  • GitHub Release draft exists → not public release evidence.
  • Publish workflow green but registry not updated yet → PUBLISHED_UNVERIFIED until independently confirmed or known propagation policy is resolved.
  • Marketplace requiring manual approval → report submission state accurately; never claim publication.

Invariants

  • Release version, commit, tag, artifact, and public metadata refer to one candidate.
  • No credential is committed or logged as release evidence.
  • Irreversible external writes require applicable authorization.
  • Public release claims are externally verified.
  • Last-minute mutation invalidates stale candidate evidence.
  • Release notes do not claim maturity/features unsupported by fresh proof.

Failure Taxonomy

Artifact omission/pollution

Package misses runtime file or includes secrets/internal material. Fix boundary, rebuild, resmoke.

Version drift

Manifests/changelog/CLI/tag disagree. Reconcile before release.

Candidate drift

CI/evidence points to older SHA after release commit changed. Rerun gates.

Tag mismatch

Existing tag points elsewhere. Stop; investigate rather than force-move.

Publish/auth failure

Candidate may remain READY_NOT_PUBLISHED. Diagnose secure auth/workflow without embedding credentials.

Registry/release mismatch

Publish reports success but public channel serves wrong/old artifact. Keep PUBLISHED_UNVERIFIED and investigate.

Clean-install failure

Artifact depends on repo-local files/dev state. NOT_READY regardless of source tests.

Anti-Patterns

  • "tests pass, publish";
  • tagging before inspecting artifact contents;
  • using source checkout as the only install test;
  • force-moving tags;
  • adding tokens to config/docs to bypass trusted publishing;
  • equating draft release with public release;
  • trusting workflow success without registry/release lookup;
  • updating docs to claim availability before public verification;
  • claiming 100% maturity while changed behavioral evidence is stale.

Release Attestation

Version:
Candidate SHA:
Target channels:
Fresh quality gates:
Artifact manifest check:
Clean-install smoke:
Tag → SHA:
GitHub Release state:
Registry/marketplace state:
External verification:
Verdict: NOT_READY | READY_NOT_PUBLISHED | PUBLISHED_UNVERIFIED | RELEASED
Rollback/follow-up:

Completion Criteria

The Skill's work completes when the requested release stage is accurately attested:

  • readiness claims are tied to exact candidate evidence;
  • artifact boundary and clean install are proven where applicable;
  • tag/release/registry states are consistent;
  • public distribution is independently verified before RELEASED;
  • missing authorization/external gates are represented as explicit state, never guessed away.

Progressive Resources

  • Deep guide: references/artifact-and-distribution-verification.md
  • Existing release gates: references/release-gates.md
  • Example: examples/release-readiness-audit.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.