Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add suryast/free-ai-agent-skills --skill static-site-release-verificationgit clone --depth 1 https://github.com/suryast/free-ai-agent-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/suryast/free-ai-agent-skills/static-site-release-verification)<a href="https://agentmods.dev/skills/suryast/free-ai-agent-skills/static-site-release-verification"><img src="https://agentmods.dev/badge/skills/suryast/free-ai-agent-skills/static-site-release-verification/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/suryast/free-ai-agent-skills/static-site-release-verification"><img src="https://agentmods.dev/badge/skills/suryast/free-ai-agent-skills/static-site-release-verification.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00044 | $0.00748 |
| Opus 5.5 | $0.00018 | $0.00299 |
| Sonnet 5.5 | $0.00009 | $0.00150 |
| Haiku 4.5 | $0.00004 | $0.00075 |
Grade A, and why
static-site-release-verification scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 34 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Static-site release verification
Establish the release contract
- Identify the repository, source revision, actual build command, output directory, deployment target, and authorized scope. Read the host's deployment provenance without changing it. Keep expected source revision and observed deployed revision separate; an upload receipt or branch tip is not deployment evidence.
- Build the reviewed revision in an isolated directory. Record dirty/untracked inputs and build tool versions. Select changed routes plus representative template routes (all routes for site-wide changes). Record exact expected content needles, canonical URLs, and referenced CSS/JS/data files from that artifact.
- Verify source-to-build content and links before deployment. Do not claim a committed artifact was tested if inputs changed after the build. Preserve raw artifacts; normalize only explicitly documented host injections, never arbitrary differences.
- If deployment is separately approved, execute it through the documented interface. This skill's checker never deploys or purges. Read back the host's exact deployed revision or immutable release ID and tie it to the tested artifact. If provenance is absent, mark revision verification unavailable; do not infer it from matching text.
- Check immutable preview and ordinary canonical production URLs separately. Use clean URLs without cache-busting queries. Compare HTML content/canonical and every selected CSS/JS/data file against local build bytes. Fresh HTML can reference stale unversioned assets. Record status, redirects, hashes, cache headers, timestamp, and tested vantage point.
- A stale edge is a release hold, not permission to purge. Request a scoped purge only if authorized; recheck the same clean URLs afterward. A passing single-edge probe is not proof of global CDN propagation. Keep content success distinct from provenance success and optional visual/accessibility checks.
Optional read-only checker
Use check_release.py with a reviewed manifest modelled on example.json. Paths are relative to --build-dir; routes and asset URLs are same-origin clean paths. List assets explicitly, including data and nonstandard HTML references: the checker does not crawl the whole site or discover dependencies. HTML verification uses UTF-8 needles and exactly one canonical; assets require exact byte equality. HTML byte parity is not required because hosts may inject markup.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 34 lines · 44 tokens per session scan A 2d5e0ddef3a1
static-site-release-verification is a skill published in the GitHub repository suryast/free-ai-agent-skills (2 stars, last pushed 6d ago), licensed MIT. It adds 44 tokens to every session and 748 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-11.
Other skills, from other repositories
publish-site
Versioned site deploys to GitHub/Cloudflare/Netlify Pages.
bumpup-versions
Consistently bump and synchronize versions across all packages in the monorepo using pnpm. Use this to ensure the root and all workspace packages share the same version number.
manage-changelog
Manage changelogs using Changie. Provides tools to initialize, add change fragments, batch releases, and merge version notes. Requires 'changie' to be installed.
ship-it
Pre-flight and deploy -- catch the classic day-one embarrassments (exposed keys, missing env vars, broken build, open endpoints), then ship to Vercel with domains and analytics wired. Use when the app is ready for other humans.
release-notes
Analyzes git commit and PR history to generate structured release notes (RELEASENOTES.md). Automatically categorizes changes, identifies contributors, and produces a polished release document through a brief confirmation interview.
land-and-deploy
Land and deploy workflow. (gstack).