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/jezweb/claude-skills/github-releasenpx skills add jezweb/claude-skills --skill github-releasegit clone --depth 1 https://github.com/jezweb/claude-skillsWhat 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.00065 | $0.00991 |
| Opus 5 | $0.00032 | $0.00495 |
| Sonnet 5 | $0.00013 | $0.00198 |
| Haiku 4.5 | $0.00006 | $0.00099 |
Grade A, and why
github-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 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 — 153 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Release
Sanitize and release projects to GitHub. Two-phase workflow: safety checks first, then tag and publish.
Prerequisites
ghCLI installed and authenticated (gh auth status)gitleaksinstalled for secrets scanning (brew install gitleaksor download from GitHub)- Git repository with a remote configured
Workflow
Phase 1: Sanitize
Run these checks before any public release. Stop on blockers.
1. Scan for Secrets (BLOCKER)
gitleaks detect --no-git --source=. --verbose
If secrets found: STOP. Remove secrets, move to environment variables. Check git history with git log -S "secret_value" — if in history, use BFG Repo-Cleaner.
If gitleaks not installed, do manual checks:
# Check for .env files
find . -name ".env*" -not -path "*/node_modules/*"
# Check config files for hardcoded secrets
grep -ri "api_key\|token\|secret\|password" wrangler.toml wrangler.jsonc .dev.vars 2>/dev/null
2. Remove Personal Artifacts
Check for and remove session/planning files that shouldn't be published:
SESSION.md— session stateplanning/,screenshots/— working directoriestest-*.ts,test-*.js— local test files
Either delete them or add to .gitignore.
3. Validate LICENSE
ls LICENSE LICENSE.md LICENSE.txt 2>/dev/null
If missing: create one. Check the repo visibility (gh repo view --json visibility -q '.visibility'). Use MIT for public repos. For private repos, consider a proprietary license instead.
4. Validate README
Check README exists and has basic sections:
grep -i "## Install\|## Usage\|## License" README.md
If missing sections, add them before release.
5. Check .gitignore
Verify essential patterns are present:
grep -E "node_modules|\.env|dist/|\.dev\.vars" .gitignore
6. Build Test (non-blocking)
npm run build 2>&1
7. Dependency Audit (non-blocking)
npm audit --audit-level=high
8. Create Sanitization Commit
What ships with it
2 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.
- 3d ago First seen · 153 lines · 65 tokens per session scan A 6c7e72bed969
github-release is a skill published in the GitHub repository jezweb/claude-skills (987 stars, last pushed 2mo ago), licensed MIT. It adds 65 tokens to every session and 991 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
release-notes
Draft short release notes from a list of changes. Use when the user asks for changelogs, release notes, or a concise product update.
qwarp
Implement QWarp features, bug fixes, referenced GitHub issues, and release work intended for the next release, including version selection, review gates, packaging, CI, and publication.
carpeos-release
Cut a CarpeOS public release with consistent SemVer, CHANGELOG, git tags, GitHub Releases, and npm publish for @innocarpe/carpeos. Use when the user asks to release, bump version, publish to npm, create a git tag, make a GitHub release, ship @innocarpe/carpeos, run scripts/release.mjs, or keep Claude Code / Codex CLI…
cfops-safe-deploy
Deploy Cloudflare Workers or the AMH WT harness with scoped credentials, dry-run checks, an immutable Git checkpoint, and a live acceptance gate. Use for deploys, releases, route changes, version bumps, or roll-forward/rollback decisions.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…
release
Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.