Borrowing it
Nothing to install: this file belongs to waldekmastykarz/atifact. 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/waldekmastykarz/atifact/main/.github/skills/bump-version/SKILL.mdgit clone --depth 1 https://github.com/waldekmastykarz/atifactWrote 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/waldekmastykarz/atifact/bump-version)<a href="https://agentmods.dev/skills/waldekmastykarz/atifact/bump-version"><img src="https://agentmods.dev/badge/skills/waldekmastykarz/atifact/bump-version.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.00057 | $0.00849 |
| Opus 5 | $0.00028 | $0.00425 |
| Sonnet 5 | $0.00011 | $0.00170 |
| Haiku 4.5 | $0.00006 | $0.00085 |
Grade A, and why
bump-version 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 8d 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Bump Version
Analyze commits since the last release tag and determine the appropriate semver version bump, then apply it using npm version.
Workflow
Follow these steps in order. Do not skip the confirmation step.
Step 1: Identify the Latest Tag
Run git tag --sort=-v:refname | head -1 to find the most recent version tag. Tags follow the v* pattern (e.g., v1.0.3).
Step 2: List Commits Since the Last Tag
Run git log <latest-tag>..HEAD --oneline to retrieve all unreleased commits. If there are no commits since the last tag, inform the user and stop.
Step 3: Determine the Version Bump Type
Analyze each commit message to classify the version bump:
- major — Any commit indicates a breaking change. Look for:
BREAKING CHANGEorBREAKING:in the message!after the type (e.g.,feat!:,fix!:)
- minor — Any commit adds new functionality. Look for:
feat:orfeat(scope):prefix- Commits describing new commands, options, or capabilities
- patch — All other changes. Common indicators:
fix:,deps:,chore:,docs:,refactor:,perf:,test:,ci:prefixes- Dependency bumps, bug fixes, maintenance tasks
Apply the highest applicable level: if any commit is major, bump major. If any commit is minor (and none are major), bump minor. Otherwise, bump patch.
Step 4: Confirm with the User
STOP — Do not proceed without user confirmation.
Present the analysis to the user:
- List the commits since the last tag
- State the recommended bump type and the reasoning
- Show what the new version number will be (current → new)
- Ask the user to confirm or choose a different bump type
Step 5: Update the Changelog
STOP — Read CHANGELOG.md before writing. Match the existing format and style.
Add a new entry at the top of CHANGELOG.md (below the # Changelog heading) for the new version:
- Use today's date and the new version number
- Add a compare link to the previous tag:
[X.Y.Z](https://github.com/waldekmastykarz/atifact/compare/vPREV...vX.Y.Z) - Group changes into sections: Features, Bug Fixes, Maintenance (only include sections that apply)
- Write human-friendly descriptions, not raw commit messages
- Only include user-facing changes — skip dependency bumps, CI changes, and internal refactors unless they affect users (e.g., minimum Node.js version change is user-facing)
- Stage the file:
git add CHANGELOG.md
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.
- 8d ago First seen · 81 lines · 57 tokens per session scan A 6be8c166daec
bump-version is a skill published in the GitHub repository waldekmastykarz/atifact (5 stars, last pushed 15d ago), licensed MIT. It adds 57 tokens to every session and 849 once invoked, about $0.0003 per session on Opus 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
automating-devops
DevOps knowledge reference covering Git workflows, testing strategies, DevSecOps, release pipeline orchestration (release.yml, multi-arch images, cosign integration), CI/CD pipelines, database management, observability, and performance optimization. Use when working with Git, CI/CD, release pipelines, ghcr image…
pypi-release
This skill should be used when releasing tunacode-cli to PyPI. It keeps the existing local release checks, then hands the actual PyPI upload to a GitHub Actions workflow that uses the repository's PYPIAPITOKEN secret.
versioning-by-impact
Use when completing a task and deciding whether repository changes require a semantic version bump and changelog entry before commit/push.
cf-ship-custom
This is a version bump + ship + release operation. Run these steps BEFORE the standard cf-ship workflow.
cf-ship
Verify, commit, push, and create a PR. Triggers: "ship it", "push and create PR", "let's ship", "create a PR", "open a pull request", "ready to merge". Supports --dry-run.
changelog
Update CHANGELOG.md with user-facing changes. Use when the user wants to update the changelog, prepare for a release, or document what changed since the last version.