Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/GhostlyGawd/codewebnpx agentmods add skills/ghostlygawd/codeweb/release-tagWrote 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/ghostlygawd/codeweb/release-tag)<a href="https://agentmods.dev/skills/ghostlygawd/codeweb/release-tag"><img src="https://agentmods.dev/badge/skills/ghostlygawd/codeweb/release-tag/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/ghostlygawd/codeweb/release-tag"><img src="https://agentmods.dev/badge/skills/ghostlygawd/codeweb/release-tag.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.00080 | $0.01552 |
| Opus 5.5 | $0.00032 | $0.00621 |
| Sonnet 5.5 | $0.00016 | $0.00310 |
| Haiku 4.5 | $0.00008 | $0.00155 |
Grade A, and why
release-tag 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 2mo 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 — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.
codeweb release runbook
A release is three moves: prep the files → land on main → push the tag. The tag push
triggers .github/workflows/release.yml, which publishes the GitHub Release server-side
with notes sliced from CHANGELOG.md — so the whole flow works from ANY environment,
including ones with no gh CLI and no GitHub-release API access (remote agent sessions).
Never commit to main directly; never push a tag until its release commit is ON main.
When to cut — don't wait to be asked
Releasing is the DEFAULT next step after user-visible work merges to main, not something to note for later. The maintainer should never have to say "cut it."
- Feature work merged, CI green,
[Unreleased]carries user-visible value → cut a minor the same day. An accumulating[Unreleased]section is a smell. - Fix-only
[Unreleased]→ patch. - A breaking CLI/tool contract → major (pre-1.0: minor, with a loud changelog note).
- Docs/CI/site-only changes → don't tag; let them ride along with the next real release.
- Unsure between two bumps? The changelog decides: any
### Addedentry = minor.
After merging a feature PR, finish the job: prep → land → tag → verify, then report the release URL. Only hold off if the maintainer has said to batch, or main is red.
0. Preconditions
- CI green on
main; working tree clean. npm testpasses locally (the full suite — the count grows release to release; a handful of environment skips are fine: golden-target-absence, optional typescript, engine-fallback inverse).node scripts/check-consistency.mjsreports OK.CHANGELOG.mdhas a meaningful[Unreleased]section — that text becomes the release notes.
1. Prep the file ecosystem
Preferred (one motion):
node scripts/release.mjs --minor # or --patch / --major / --version=X.Y.Z
It bumps package.json, rolls [Unreleased] into ## [X.Y.Z] - <today> (+ link refs),
version-syncs plugin.json / SKILL.md / README badge / the mcp-server version literal,
rebuilds the site, and re-runs the consistency check. It never touches git.
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.
- 2mo ago First seen · 123 lines · 80 tokens per session scan A 607f81456af0
release-tag is a skill published in the GitHub repository GhostlyGawd/codeweb (0 stars, last pushed 4d ago), licensed MIT. It adds 80 tokens to every session and 1,552 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
ship
An automated release workflow that commits current changes, pushes them, opens and merges a pull request, and cleans up the branch. A pull request is a proposed code change for review; the workflow adapts to repositories using either a develop branch or direct feature-to-main merging.
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
ops-release
OPS on-demand: This skill should be used when the user asks to "release the plugin", "publish ops…
release
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and create the GitHub release. Use when shipping a new plugin version. NOT distributed.
han-release
Cut a Han release: update CHANGELOG.md with the changes since the last release, bump and tag every plugin that changed as {plugin-name}--v{version} so a version-constrained dependency can resolve, and publish a GitHub release crediting every merged pull request and closed issue to the people behind it. Use when…
push-ci
Push to remote and monitor CI. Validates branch safety, executes git push WITH explicit user approval, then monitors CI run status via gh CLI. Use when: user says 'push', 'push and watch CI', 'ship it', 'push-ci'. Not for: committing (use /smart-commit), creating PRs (use /create-pr), merging (use /merge-prep).