Borrowing it
Nothing to install: this file belongs to petarzarkov/dunx. 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/petarzarkov/dunx/main/.claude/skills/release/SKILL.mdgit clone --depth 1 https://github.com/petarzarkov/dunxWrote 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/petarzarkov/dunx/release)<a href="https://agentmods.dev/skills/petarzarkov/dunx/release"><img src="https://agentmods.dev/badge/skills/petarzarkov/dunx/release.svg" alt="Measured on agentmods" 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.00061 | $0.02063 |
| Opus 5 | $0.00030 | $0.01032 |
| Sonnet 5 | $0.00012 | $0.00413 |
| Haiku 4.5 | $0.00006 | $0.00206 |
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 7d 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.
This is a copy
86% identical to sentry-instrumentation — 177 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/release
Releases are lockstep: every @dunx/* package shares one version and ships
together, even the ones a release did not touch. Change detection decides whether
to release, never what. The reason is a correctness one - a published range names a
concrete version of @dunx/core, so independent versions would let an app end up
with two copies of it, and in this container a token is a class object. Full
reasoning: architecture/packaging.md, "Versioning is lockstep".
Do not make versions independent again without also solving the duplicate-core problem - see that section for the two alternatives and why each was rejected.
CI runs bun run version on every push to main, and it publishes nothing unless
the head commit is a release commit. Ordinary merges run the checks and deploy the
docs. This skill is for cutting a release deliberately, and for the failure modes.
Cutting a release
-
/ci-check- build, lint, typecheck, test. A failed build publishes nothing, but a passing build with brokendist/publishes broken. -
Run the
publish-guardagent over the changed packages. -
bun run version:dry-run- on a non-release commit this reports that it would skip. It prints the computed bump, the commits it read, and the changed packages. -
Commit the release trigger and push to
main:Subject Bump release: <summary>derived from every commit since the last release release(major|minor|patch): <summary>stated outright release!: <summary>major The trigger is matched on the subject only, so a body quoting the word does not publish.
The bump and the changed-package detection both span every commit back to the
previous chore(release): bump version to ... marker. That marker is
RELEASE_COMMIT_PREFIX in scripts/bump.ts, written by pushVersionCommit in
scripts/version.ts - if you change one, change both, or every range becomes "all
of history". CI's fetch-depth: 0 is load-bearing for the same reason: a shallow
checkout cannot see the marker and silently under-reports the bump to a patch.
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.
- 7d ago First seen · 138 lines · 61 tokens per session scan A 6130a6c63801
release is a skill published in the GitHub repository petarzarkov/dunx (21 stars, last pushed today), licensed MIT. It adds 61 tokens to every session and 2,063 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 86% identical to sentry-instrumentation, differing in 177 lines, and is treated as a copy.
Other skills, from other repositories
nestjs
Use when building or structuring a NestJS backend — feature modules, providers and DI wiring, provider scopes and request-lifecycle order, where to bind guards/pipes/interceptors/filters, and testing with Test.createTestingModule. NOT a bare Express/Fastify service with no DI (that is nodejs), NOT framework-agnostic…
update-skills
Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says "learn!", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.
sync
Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
merge
Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.
update-pr
Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.
dev-fix
Unified developer workflow for fixing bugs. Analyzes issue-tracker context, cross-checks docs/code, proposes a solution, implements the fix, verifies locally, and delivers a PR/MR.