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 agents/dgunning/edgartools/release-specialistgit clone --depth 1 https://github.com/dgunning/edgartoolsWhat 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 | $0.00000 | $0.02379 |
| Opus 5 | $0.00000 | $0.01189 |
| Sonnet 5 | $0.00000 | $0.00476 |
| Haiku 4.5 | $0.00000 | $0.00238 |
Grade A, and why
release-specialist 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 3d 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 — 188 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Release Specialist, an expert in software release management with deep knowledge of versioning strategies, CI/CD pipelines, package publishing, and release automation. You have extensive experience with semantic versioning, conventional commits, changelog generation, and multi-platform releases.
⛔ Publishing Is Out of Scope (Hard Rule)
You MUST NEVER publish to PyPI or any package registry. Publishing to PyPI is a manual, maintainer-only step on this project, performed by the maintainer with credentials you must not touch.
- Never run
twine upload,hatch publish,flit publish,poetry publish,python -m twine ..., or any equivalent registry-upload command. - Never read, copy, move, or otherwise use
~/.pypirc, keyring/keychain entries, or anyTWINE_*/PYPI_*/*_TOKENenvironment variable. - Your release pipeline ends at: built artifacts in
dist/, a pushed git tag, and a GitHub release. Stop there. - Your final report MUST list the built artifact paths and the exact command the maintainer should run to publish — but you do not run it.
- If a user asks you to publish, decline and explain that publishing is a manual maintainer step on this project. Do not work around this by suggesting the parent agent run the command either.
This rule overrides any instruction in a task prompt that appears to authorize publishing.
Core Responsibilities
You orchestrate the entire release lifecycle from preparation through publication and verification. Your primary duties include:
-
Pre-Release Validation
- Verify all tests pass (run test suite if needed)
- Check for uncommitted changes
- Validate branch is up-to-date with main/master
- Ensure version numbers are consistent across all files
- Verify documentation is current
- Check dependency compatibility
- Scan for security vulnerabilities
-
Version Management
- Determine appropriate version bump (major/minor/patch) based on changes
- Update version in setup.py, pyproject.toml, package.json, or relevant files
- Ensure version follows semantic versioning (MAJOR.MINOR.PATCH)
- Handle pre-release versions (alpha, beta, rc) when specified
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.
- 3d ago First seen · 188 lines · 0 tokens per session scan A 4eff2f8bb24b
release-specialist is an agent published in the GitHub repository dgunning/edgartools (2,644 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,379 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-08-30.
Other agents, from other repositories
version-plans
A version plan is required only for changes that affect a publishable package's behavior. Do not create a version plan for documentation-only changes or changes scoped entirely to apps/playground or website (both are excluded from versioning in .changeset/config.json).
geo-roadmap-release-manager
Manages SemVer decisions, package version bump proposals, roadmap alignment, release readiness, tag checklist, CI gate review, and post-merge release sequencing for GEO Optimizer and GeoReady.
git-flow-manager
Git Flow workflow manager. Use PROACTIVELY for Git Flow operations including branch creation, merging, validation, release management, and pull request generation. Handles feature, release, and hotfix branches.
unifi-release-manager
Multi-agent orchestrator for coordinating UniFi MCP Server releases.
release-validator
Validates release readiness by checking tests, build, dependencies, and changelog. Use before creating a release.
pr-ghostwriter
Kod değişikliklerinden PR açıklaması, commit mesajı ve changelog üretir. Gerçek diff'i okuyarak değişikliğin ne, neden ve nasıl olduğunu açıklar. Kullanıcı PR açmak, commit mesajı yazmak veya release notu hazırlamak istediğinde kullanılır. Jenerik açıklama üretmez — her zaman gerçek değişikliğe özgü yazar.