Borrowing it
Nothing to install: this file belongs to PIsberg/vibetags. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/PIsberg/vibetags/main/.claude/skills/release/SKILL.mdgit clone --depth 1 https://github.com/PIsberg/vibetagsWrote 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/pisberg/vibetags/release)<a href="https://agentmods.dev/skills/pisberg/vibetags/release"><img src="https://agentmods.dev/badge/skills/pisberg/vibetags/release/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/pisberg/vibetags/release"><img src="https://agentmods.dev/badge/skills/pisberg/vibetags/release.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Agent Snooping · line 88 Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.Fix: Remove all code or instructions that list or read other skills' files or directories. Skills should operate independently; cross-skill access is a privilege escalation.
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.00071 | $0.04493 |
| Opus 5.5 | $0.00028 | $0.01797 |
| Sonnet 5.5 | $0.00014 | $0.00899 |
| Haiku 4.5 | $0.00007 | $0.00449 |
Grade A, and why
release 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 12d 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 — 361 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release VibeTags
Drives the release process documented in docs/RELEASING.md. That document is the
source of truth; this skill is the executable path through it. If the two ever
disagree, docs/RELEASING.md wins — and say so rather than silently improvising.
Step 1 — Establish the current version and ask for the next one
The single source of truth for "what version are we on" is the <revision>
property in vibetags-parent/pom.xml:
sed -n 's:.*<revision>\(.*\)</revision>.*:\1:p' vibetags-parent/pom.xml | head -n1
git tag --sort=-v:refname | head -5
Then ask the user which version to release with AskUserQuestion. Compute the
candidates from whatever the current version turns out to be — do not hardcode them:
- If the current version is a release candidate (
X.Y.Z-RCn), offer promoting it to final (X.Y.Z) and cutting the next candidate (X.Y.Z-RC<n+1>). - If the current version is final, offer the patch, minor, and major bumps, and a first
release candidate for the next minor if that fits what is in
[Unreleased].
Always include the semantic-versioning meaning in each option's description. The user can also type any version via "Other". Never guess and proceed — the version is always the user's call.
Sanity-check the answer before continuing: it must be a release version (no
-SNAPSHOT — Maven Central rejects those), and git tag -l "v<version>" must come
back empty.
Step 1b — Count this month's releases against Central's allowance
Maven Central allows an organization 7 releases, 1,167 files and 78 MB a month, and an org that stays over them is rate limited (#863). September 2026 had 7 tags. Count this calendar month's tags before going further:
git for-each-ref --format='%(creatordate:format:%Y-%m) %(refname:short)' 'refs/tags/v*' \
| grep "^$(date +%Y-%m) "
The cadence is at most 3 releases a month. If this would be the fourth or later, stop and tell the user the count, and continue only on an explicit go-ahead for a fix a consumer is blocked on. Say which it was in the release PR body.
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.
- 12d ago Changed · +28 lines f375ad3f1c40
- 13d ago Changed cf93cb5e814d
- 14d ago Changed · +1 lines 36a94ef4690a
- 15d ago Changed · +15 lines 5fd885eeb6de
- 26d ago Changed · +1 lines c5c3eea052da
- 29d ago Changed bebe7a4dc372
- 1mo ago Changed · +5 lines d0a532c9f5f1
- 1mo ago Changed · +1 lines dd1e4762ddd1
- 1mo ago Changed · +12 lines 7e6af8aac918
- 1mo ago First seen · 298 lines · 71 tokens per session scan A 7f95c615ec45
release is a skill published in the GitHub repository PIsberg/vibetags (25 stars, last pushed today), licensed MIT. It adds 71 tokens to every session and 4,493 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-30.
Other skills, from other repositories
release-pr-review
Review pass on an open release PR (release/ → main) — the step between git-wrapup and release-and-publish when a project releases in gated release PR mode. Reads the PR's commit range through the code-simplifier lens plus a correctness review, verifies whatever an automated reviewer left on the PR, lands fixes as…
version-control-strategy
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use design-system-governance (design-systems).
git-commit
Generate conventional commit messages for Java projects. Use when user says "commit", "create commit", "commit changes", or after completing code changes that need to be committed.
debug-systematic
Systematic 4-phase debugging methodology for complex, intermittent, or mysterious issues. Use when investigating bugs, race conditions, or unexplained failures.
monorepo-navigator
Inspect or improve Turborepo, Nx, pnpm, or Lerna monorepos: package boundaries, dependency graphs, selective tests, caching, and migrations.
github-ops
GitHub remote operations and README authoring: repo creation, metadata, releases, issue/PR management with preview-before-send, README as a landing page (badge row, features-as-benefits, screenshots, Recent Updates), and read-only security auditing. Triggers on: write a README, improve the README, README badges…