Borrowing it
Nothing to install: this file belongs to mdrideout/junjo. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mdrideout/junjo/master/.agents/skills/junjo-release-descriptions/SKILL.mdgit clone --depth 1 https://github.com/mdrideout/junjoWrote 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/mdrideout/junjo/junjo-release-descriptions)<a href="https://agentmods.dev/skills/mdrideout/junjo/junjo-release-descriptions"><img src="https://agentmods.dev/badge/skills/mdrideout/junjo/junjo-release-descriptions/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mdrideout/junjo/junjo-release-descriptions"><img src="https://agentmods.dev/badge/skills/mdrideout/junjo/junjo-release-descriptions.svg" alt="Reviewed on agentmods" width="80" 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.00070 | $0.01249 |
| Opus 5.5 | $0.00028 | $0.00500 |
| Sonnet 5.5 | $0.00014 | $0.00250 |
| Haiku 4.5 | $0.00007 | $0.00125 |
Grade A, and why
junjo-release-descriptions 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 1mo 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 — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Junjo Release Descriptions
Outcome
Produce an accurate release page that quickly explains what the component is, what people can now accomplish, what changed for existing users, and where technical readers can verify the release. Preserve the release transaction and its provenance evidence.
Scope and authorization
- Treat the Python SDK and Studio as independently versioned products with
namespaced
sdk-python-v*andstudio-v*tags. - When a request refers to the latest Junjo releases, inspect the live release list and normally handle the newest stable release for each named or active component. Do not rewrite older releases unless requested.
- Drafting and review are read-only. Change a live GitHub description only when the user asked to create, improve, update, or publish it.
- Edit only the requested release body. Do not create or move tags, create or republish releases, change release state or title, upload or remove assets, or mark a different release as latest unless explicitly requested.
- Never use
gh release createmerely to add a description. Publishing an SDK release triggers the PyPI workflow; description work must not initiate a release transaction.
Establish the shipped facts
- Read the root
AGENTS.mdand the scoped owner guidance for any component whose behavior must be interpreted. - Inspect the live release body and metadata with
gh release list,gh release view, or the GitHub API. Confirm the exact tag and target commit before writing. - Compare the release tag only with the previous tag in the same namespace. Never let a Studio tag become the SDK comparison base, or vice versa.
- Read evidence at the release tag, not only the current worktree:
- SDK:
sdks/python/CHANGELOG.md, its README, shipped guides, examples, and relevant public tests. - Studio: the tagged diff,
apps/studio/README.md, deployment READMEs, accepted ADRs, user-facing frontend behavior, and relevant tests. - Paired versions:
tooling/docs/stable-releases.jsonand the canonical deployment distributions. - Product language: the tagged component README and public website source.
- SDK:
- Treat post-tag commits as unreleased. Every product claim, compatibility statement, removal, and upgrade warning must be supported by the tagged release.
- For Studio, preserve the validated source, workflow, image digests,
distribution hashes, mirror revisions, and attached release evidence. The
deterministic evidence generated by
tooling/scripts/build_studio_release_evidence.pyis provenance, not editorial copy. - Verify operational instructions against the actual tagged configuration, Compose mounts, migrations, and deployment behavior. If documentation and implementation disagree, state only the confirmed high-level warning in the release and report the discrepancy separately; do not invent a procedure.
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.
- 1mo ago First seen · 112 lines · 70 tokens per session scan A 29b6f912bcef
junjo-release-descriptions is a skill published in the GitHub repository mdrideout/junjo (20 stars, last pushed 17d ago), licensed Apache-2.0. It adds 70 tokens to every session and 1,249 once invoked, about $0.0003 per session on Opus 5.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-13.
Other skills, from other repositories
changelog
Turn a range of commits or merged PRs into a changelog entry grouped by change type. Use when the user asks for release notes, a changelog, or "what changed" between two points.
otto-drive-pr
PR mergeability, CI, and live preview.
changelog
Update per-package CHANGELOG.md files for a Ratel release. Drafts entries with git-cliff (scoped per package), lets you curate, then writes the CHANGELOGs. Handles both RC entries and GA-graduation collapse (merging X.Y.Z-rc. sections into a single X.Y.Z section). Invoke before tagging a release.
jira-release
Assemble a release from a batch of Jira issues — one release branch, pull request, preview and tracking issue per repository — and, when a person says to ship it, merge it and move the cards on. Insert into the prompt of a run started on a batch of issues.
ship
Enter the Ship phase of CocoBrew. Reads review.md approval, generates structured commit, creates semantic version tag, optionally creates PR via gh CLI, and records deployment details. Requires approved review.
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…