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/salitaba/maven-decoder-mcpnpx agentmods add skills/salitaba/maven-decoder-mcp/project-releaseWrote 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/salitaba/maven-decoder-mcp/project-release)<a href="https://agentmods.dev/skills/salitaba/maven-decoder-mcp/project-release"><img src="https://agentmods.dev/badge/skills/salitaba/maven-decoder-mcp/project-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/salitaba/maven-decoder-mcp/project-release"><img src="https://agentmods.dev/badge/skills/salitaba/maven-decoder-mcp/project-release.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.00000 | $0.00919 |
| Opus 5 | $0.00000 | $0.00460 |
| Sonnet 5 | $0.00000 | $0.00184 |
| Haiku 4.5 | $0.00000 | $0.00092 |
Grade A, and why
project-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 yesterday.
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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project Release
Ship a new version of maven-decoder-mcp end to end. The tag is the single source of truth — CI rewrites every version file from it — so the release is mostly ceremony plus verification.
Rules
- Never reuse a version number. If a publish partially succeeded, bump patch and release again (npm refuses republished versions).
- Never retag or force-push a tag after any artifact published. Fix forward.
- Release flow is documented in
RELEASING.md; the authoritative process details live inRELEASE_GUIDE.mdand.github/workflows/release.yml. scripts/release.pyandsimple_release.share legacy and must not be used for real releases — they hardcode v1.0.0 and push a wrong image name.
Workflow
1. Decide the version
Inspect commits since the last tag (git log <last-tag>..HEAD --oneline).
SemVer: patch for fixes, minor for new tools/features, major for breaking
changes. Confirm with the user when ambiguous — the tag cannot be undone
once artifacts publish.
2. Run the gate locally
MAVEN_OFFLINE=true .venv/bin/python -m pytest tests/ -q --no-cov
.venv/bin/python run_tests.py
.venv/bin/python test_startup.py
.venv/bin/python -m build && .venv/bin/python -m twine check dist/*
Do not proceed on failure. All four must pass.
3. Draft release notes
python3 scripts/generate_release_notes.py --tag vX.Y.Z
Read the generated RELEASE_NOTES.md, fix anything the commit subjects got
wrong (the generator groups by feat:/fix: prefixes), and keep the focus
on what a user upgrading needs to know: new tools, behavior changes, breaks.
Commit the notes on main before tagging — CI uses the committed file as the
release body and regenerates from history only if it does not cover the tag.
4. Commit, tag, push
git add -A && git commit -m "release: vX.Y.Z"
git tag -a vX.Y.Z -m "Maven Decoder MCP Server vX.Y.Z"
git push origin main && git push origin vX.Y.Z
5. Watch CI to green
The Release workflow runs test (3.10/3.11/3.12) → build
(PyPI + npm + GitHub release) → docker (multi-arch push). Watch all three:
What ships with it
1 file 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.
- yesterday First seen · 96 lines · 0 tokens per session scan A a391c67e5574
project-release is a skill published in the GitHub repository salitaba/maven-decoder-mcp (20 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 919 tokens. 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-09-09.
Other skills, from other repositories
release
Generic release assistant — analyzes repo release rules, caches them in .omc/RELEASERULE.md, then guides the release.
land-and-deploy
Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.
merge
The ship gate — the only skill that merges. --staging merges the feature→staging PR on green CI, deploys, verifies, emits a human test script and stamps the staging sign-off on approval. --production ships the double-confirmed release to main and deploys production. Never self-certifies staging; nothing reaches main…
gitlab-devops
GitLab DevOps operations — issues, merge requests, CI/CD pipelines, repository browsing, labels, milestones, releases, and wiki management. Use when querying GitLab project status, monitoring pipeline executions, browsing repository files, creating issues for network findings, opening merge requests for config…
seed-snapshot-release
An automated workflow for creating and tracking a snapshot release of the pull request on the current branch. A snapshot release is a temporary package build used for testing a branch before a normal release.
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).