Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/dwmkerr/claude-toolkit/release-please-developmentnpx skills add dwmkerr/claude-toolkit --skill release-please-developmentgit clone --depth 1 https://github.com/dwmkerr/claude-toolkitWrote 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/dwmkerr/claude-toolkit/release-please-development)<a href="https://agentmods.dev/skills/dwmkerr/claude-toolkit/release-please-development"><img src="https://agentmods.dev/badge/skills/dwmkerr/claude-toolkit/release-please-development.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.00054 | $0.01077 |
| Opus 5 | $0.00027 | $0.00539 |
| Sonnet 5 | $0.00011 | $0.00215 |
| Haiku 4.5 | $0.00005 | $0.00108 |
Grade A, and why
release-please-development 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 6d 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 — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Please Development
Configure automated versioning, changelog generation, and releases using Google's release-please.
Quick Reference
- Single Package Pattern - Simple repos with one version
- Multi-Package Pattern - Monorepos with independent versions
- Configuration Options - All available settings
Overview
Release-please automates:
- Version bumping based on conventional commits
- CHANGELOG.md generation
- GitHub release creation
- Version updates in files (package.json, Chart.yaml, etc.)
Core Files
.github/
├── release-please-config.json # Package configuration
├── release-please-manifest.json # Current version tracking
└── workflows/
└── release.yaml # GitHub Actions workflow
When to Use Each Pattern
| Pattern | Use Case |
|---|---|
| Single Package | Libraries, CLIs, simple apps with one version |
| Multi-Package | Monorepos, services with independent release cycles |
Basic Setup
1. Create Config File
.github/release-please-config.json:
{
"release-type": "simple",
"packages": {
".": {
"changelog-path": "CHANGELOG.md"
}
}
}
2. Create Manifest
.github/release-please-manifest.json:
{
".": "0.0.1"
}
3. Add GitHub Workflow
.github/workflows/release.yaml:
name: Release
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: googleapis/release-please-action@v4
with:
config-file: .github/release-please-config.json
manifest-file: .github/release-please-manifest.json
Release Types
| Type | Use Case | Versions |
|---|---|---|
simple |
Generic projects | CHANGELOG only |
node |
npm packages | package.json |
python |
Python packages | setup.py, pyproject.toml |
go |
Go modules | go.mod |
helm |
Helm charts | Chart.yaml |
What ships with it
3 files 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.
- 6d ago First seen · 178 lines · 54 tokens per session scan A 5a76f254d3cd
release-please-development is a skill published in the GitHub repository dwmkerr/claude-toolkit (23 stars, last pushed 11d ago), licensed MIT. It adds 54 tokens to every session and 1,077 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-30.
Other skills, from other repositories
ship
Ship workflow: detect + merge base branch, run tests, review diff, bump VERSION, update CHANGELOG, commit, push, create PR. (gstack).
github-release-management
Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management.
agent-github-modes
Agent skill for github-modes - invoke with $agent-github-modes.
tutti-app-release
Set up, review, run, or debug external repositories that publish a Tutti workspace app through the reusable Tutti App Release GitHub Actions workflow. Use for caller workflows, tutti.app.json manifests, @tutti-os/app-release-tools, S3/CloudFront release hosting, latest.json, versions.json, catalog.json, catalog-only…
harness-release
Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup.
publish
Publish the Octop Python package: cut a release branch from develop, bump version, update CHANGELOG, open a PR to main; after merge, Actions tag on main (PyPI / Docker Hub + GHCR) and sync main into develop. Use when the user asks to publish, release, bump version, cut a release, or run /publish.