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/paruff/ufawkesai/releasenpx skills add paruff/uFawkesAI --skill releasegit clone --depth 1 https://github.com/paruff/uFawkesAIWrote 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/paruff/ufawkesai/release)<a href="https://agentmods.dev/skills/paruff/ufawkesai/release"><img src="https://agentmods.dev/badge/skills/paruff/ufawkesai/release.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.00056 | $0.01953 |
| Opus 5 | $0.00028 | $0.00977 |
| Sonnet 5 | $0.00011 | $0.00391 |
| Haiku 4.5 | $0.00006 | $0.00195 |
Grade A, and why
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 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.
How it starts
The opening of the file, as written. The whole thing — 232 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: Release
Load trigger:
"load release skill"> DORA: AI Capability 4 (Strong version control) + Core: Continuous Delivery Token cost: Low
Purpose
Make "one new thing a week" a checklist execution, not a creative decision each time. Source material is written once (README "What This Is" + "Status" sections) and reformatted four times: CHANGELOG entry, GitHub Release notes, dev.to post, LinkedIn post. The fifth output — ufawkes.dev stack page update — is a one-line front matter change.
Write-Once, Ship-Four-Times Pattern
README "Status" + "What This Is"
│
├─→ CHANGELOG entry (3-5 bullet points, past tense)
│
├─→ GitHub Release notes (CHANGELOG + context sentences)
│
├─→ dev.to post (Why→What→How→Proof→Next structure, 400-800 words)
│
└─→ LinkedIn post (hook + 3 paragraphs, max 200 words)
└─→ ufawkes.dev stack page (one-line front matter: latest_version, coming_soon)
Semver Decision Table
| Change type | Bump | Example |
|---|---|---|
| Breaking change to public API or golden path interface | MAJOR (v1.0.0) | Removing a supported config key |
| New capability, backward compatible | MINOR (v0.x.0) | Adding a new Grafana dashboard |
| Bug fix, doc update, dependency update | PATCH (v0.x.y) | Fixing a broken healthcheck |
| Documentation only, no behavior change | PATCH | README update, CONTRIBUTING.md filled in |
When in doubt, PATCH. Never hold a PATCH for a MINOR.
Release Checklist
Phase 1 — Triage (10 min)
# List open issues, check for blockers
gh issue list --repo paruff/REPO_NAME --state open \
--json number,title,labels \
--jq '.[] | "\(.number): \(.title) [\(.labels[].name // "unlabeled")]"'
# Label blockers — STOP if any found, resolve first
gh issue edit ISSUE_NUMBER --repo paruff/REPO_NAME --add-label "release-blocker"
# Label future work
gh issue edit ISSUE_NUMBER --repo paruff/REPO_NAME --add-label "v0.2"
gh issue edit ISSUE_NUMBER --repo paruff/REPO_NAME --add-label "later"
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 · 232 lines · 56 tokens per session scan A d75add60e26f
release is a skill published in the GitHub repository paruff/uFawkesAI (2 stars, last pushed 13d ago), licensed MIT. It adds 56 tokens to every session and 1,953 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-03.
Other skills, from other repositories
infrastructure-publishing
Skill for the publishing infrastructure module providing academic publishing workflows including BibTeX CLI citation generation, APA/MLA citation helper functions, DOI management, Zenodo publication, arXiv submission preparation, GitHub releases, PyPI and TestPyPI package distribution, static-site deployment to GitHub…
template-publish
Publishing scripts for DOI-bearing project releases, optional mirror uploads, PyPI release validation, post-publish verification, and publication export. Use with docs/guides/publication-runbook.md for standalone GitHub + Zenodo release workflows.
ship
Use when a change is ready to land. Runs the full sequence — branch, quality gate, commit, push, PR — so nothing gets skipped.
skill-skill
Use this skill when the user has a working AI rule or skill file and wants to package and publish it as a GitHub repository end to end. Trigger when the user says 'I have a skill, help me publish it', 'turn my prompt into a GitHub repo', 'publish my Cursor rule', 'put this skill on GitHub end to end', 'walk me through…
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…
finishing-a-development-branch
当实现完成、所有测试通过、需要决定如何集成这份工作时使用.