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 skills add lfyxhappy/lfcode --skill git-release-managergit clone --depth 1 https://github.com/lfyxhappy/lfcodeWrote 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/lfyxhappy/lfcode/git-release-manager)<a href="https://agentmods.dev/skills/lfyxhappy/lfcode/git-release-manager"><img src="https://agentmods.dev/badge/skills/lfyxhappy/lfcode/git-release-manager.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.00376 |
| Opus 5 | $0.00028 | $0.00188 |
| Sonnet 5 | $0.00011 | $0.00075 |
| Haiku 4.5 | $0.00006 | $0.00038 |
Grade A, and why
git-release-manager 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 2d 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.
What it actually says
Git Release Manager
Make release state reproducible and reviewable from source to published artifact.
Workflow
- Read repository release instructions and templates. Check the current branch, upstream, worktree status, staged changes, version sources, changelog, and release history.
- Confirm the target version, branch, tag, remote, release channel, artifact set, and whether the user authorized commit, tag, push, or hosted-release actions.
- Prepare only the requested release metadata. Use the repository's conventional commit and package commands, regenerate generated outputs only when required, and preserve unrelated changes.
- Run the appropriate package tests, typechecks, builds, packaging checks, and artifact integrity checks. Inspect version consistency and installer names.
- Before irreversible actions, show or verify the final diff and release summary. Create the commit, tag, push, and hosted release only within the confirmed scope.
- Record commit and tag identifiers, artifact locations, verification results, and the recovery path such as deleting an unpushed tag or correcting a release entry.
Boundaries
- A clean build does not authorize a push or release. Do not infer approval for external GitHub or registry writes.
- Never force-push, rewrite shared history, expose tokens, or paste private remote URLs and credentials into logs.
- If the worktree contains unrelated edits, isolate the release change or stop before staging broad paths.
Completion check
Distinguish prepared, committed, pushed, and published states. Report each actual result and each skipped or unavailable step.
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.
- 2d ago First seen · 28 lines · 57 tokens per session scan A cfce969a2062
git-release-manager is a skill published in the GitHub repository lfyxhappy/lfcode (2 stars, last pushed 5d ago), licensed MIT. It adds 57 tokens to every session and 376 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-09-05.
Other skills, from other repositories
npm
Publish and manage packages on the npm registry (npmjs.com), publish, dist-tags, deprecate, owners, download stats, private installs. Use when the user asks to publish, release or manage an npm package, or to inspect the registry.
release-verification
A release-verification checklist for software versions and packages. It covers changelogs, tests, packaging, installation smoke checks, version-control actions, publishing, and checks after release.
audit-release
A pre-release review assistant that checks whether a software package or plugin is ready to publish.
PR babysit (watch & drive to green)
Watch a pull request and delegate fixes until CI is green and reviews are addressed. Requires the GitHub MCP server or gh.
release-app
Cut a workhub release — bump the app version, write the changelog entry, commit to main, tag vX.Y.Z, push, and verify the GitHub Release published with every required asset. Use when the user wants to release or ship the workhub app, tag a version, or publish a build.
Commit (clean, conventional)
Stage the right changes and write a clear, conventional commit message.