release-verification skillA
release-verification is agent-read markdown (skill) from nahid-sparktales/agent-dispatcher: Prove a deployment is healthy rather than merely finished — the revision actually serving asked of the running system, every instance moved, smoke paths walked against the real environment, error rate and latency compared to a pre-deploy baseline. Use after any deploy to a shared environment, before a release is called good, or when checking someone else's claim that it went fine. Not for planning the rollout (deployment) or executing a revert (rollback); it never accepts a green pipeline, a 200.
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Release verification "The deploy finished" is a fact about a pipeline. It says nothing about which revision is serving, whether all of it is serving, or whether the thing serving works. Those are three separate questions and this procedure answers them in that order. ## When this fires A deploy has completed to any shared environment and someone is about to call the release good — your deploy or somebody else's. It fires again after every rollback, hotfix and re-run. It does not fire for a build, and it is not a substitute for tests. ## Procedure 1. **Write down what healthy means before you look.** Which signals, what threshold, over what window, compared to what baseline. Deciding after seeing the numbers is how a bad release gets talked into being fine. 2. **Capture the pre-deploy baseline**, or declare it missing. Error rate, latency at the percentile that matters, throughput, saturation — from before the change. Without it you can report absolute numbers but you cannot say the release did not make anything worse. Say that in those words. 3. **Ask the running system which revision it is serving.** A version or build-info surface the …
Read the whole file at its exact version.
How to install
mdr add nahid-sparktales/agent-dispatcher/release-verification@git:20260919.a0d4f55mdr add nahid-sparktales/agent-dispatcher/release-verification@sha256:25d9bb3e9d3d8242Pin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_zzusto2eihkfzy7m)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (7161 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
nahid-sparktales/agent-dispatcher · 49 stars · license MIT · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_zzusto2eihkfzy7m GET https://markdownregistry.com/api/v1/resolve?ref=nahid-sparktales/agent-dispatcher/release-verification GET https://markdownregistry.com/api/v1/blob/25d9bb3e9d3d8242ff7f9b427493427a719668438693f7f34f199d7d4bcd6a70
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
More from nahid-sparktales/agent-dispatcher
Every file in nahid-sparktales/agent-dispatcher