Borrowing it
Nothing to install: this file belongs to st0012/cctop. 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/st0012/cctop/master/.agents/skills/release/SKILL.mdgit clone --depth 1 https://github.com/st0012/cctopWrote 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/st0012/cctop/release)<a href="https://agentmods.dev/skills/st0012/cctop/release"><img src="https://agentmods.dev/badge/skills/st0012/cctop/release/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/st0012/cctop/release"><img src="https://agentmods.dev/badge/skills/st0012/cctop/release.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Rogue Agent · line 24 Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.Fix: Prevent the skill from modifying its own code, SKILL.md, or configuration files. Treat skill files as read-only at runtime.
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.00082 | $0.01228 |
| Opus 5.5 | $0.00033 | $0.00491 |
| Sonnet 5.5 | $0.00016 | $0.00246 |
| Haiku 4.5 | $0.00008 | $0.00123 |
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 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cutting a cctop Release
Releases are triggered by pushing a v* tag. .github/workflows/release.yml then runs: build (arm64 + x86_64, zip + DMG each) -> sign and notarize -> create GitHub Release -> update Sparkle appcast on master -> update Homebrew cask.
Authorization and checks
- Treat an explicit request to release, cut, or ship a version as authorization for the complete release: assess scope, run proportionate checks, bump and land the version, push the tag, supervise publication, and verify downstream metadata. Do not insert another routine approval gate when all expected checks pass.
- A request to prepare, assess, or check whether ready is not publication authorization. Stop before the tag and ask for the final go.
- Before proposing or adding any release check, state its reason in plain language: name the concrete failure or release risk it covers and why the shipped changes make that risk relevant. Do not propose a check merely because an older or larger release used it.
- Scale checks to the release. Previously approved PR tests are feature evidence; release checks should cover integration, versioning, packaging, and risks introduced by the exact release range. Patch releases should not inherit major-release manual tests without a specific reason.
- Once an authorized release's checks pass, continue automatically. Stop only when a check fails unexpectedly, the release range/version is ambiguous, unrelated changes appear, publication requires a genuinely new product decision, or the developer asks to pause.
- Never merge feature PRs; the developer merges them. The approved release bump may land by the agreed repository path.
1. Establish the release contract
- Sync and review what's shipping:
git pullthengit log $(git describe --tags --abbrev=0)..origin/master --oneline. - Propose or confirm the semver bump and a short changelog summary.
- State how the bump commit will land. Direct push to master is allowed for this repo; most releases use this path. Use a PR if the developer prefers.
- List the release checks and give one concise reason for each. Remove checks whose reason is only habit or duplication of already-approved feature evidence.
- If the developer explicitly requested the release and the version/scope are clear, continue. If they only requested preparation/readiness assessment, stop for approval.
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 · 67 lines · 82 tokens per session scan A 68331fe9285e
release is a skill published in the GitHub repository st0012/cctop (159 stars, last pushed 22d ago), licensed MIT. It adds 82 tokens to every session and 1,228 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-08-30.
Other skills, from other repositories
todos
Use when the user asks for a shared plan, a task needs at least three substantive execution steps, or a loose TODO is pending. Without an explicit plan request, not for one-shot answers or checks, or one- to two-step work that is not already in the list.
shipping-a-pr
Use when finished work needs to ship as a pull request, or when creating, syncing, updating metadata, checking status, monitoring CI, or addressing review comments on a PR. Not for reviewing a PR you are not shipping.
ring:generating-release-guides
Generating an internal Operations-facing update/migration guide from the git diff between two refs, documenting per-change client impact, deploy ordering, monitoring, and rollback notes in English, pt-br, or both. Use when preparing a version release or recording what changed for the Ops team. Runs read-only by…
makefile
Use when creating or updating a Makefile for a project, especially when standard targets (build, test, lint, format, etc.) are missing or when modifying targets that may already be wired into other tooling. Not for debugging why a build fails.
checkpoint-management
Git-backed state management for safe rollback. Create and restore checkpoints with tagged commits and metadata tracking.
maintainer-bar
Operate the MaintainerBar SwiftUI menu bar app and its ghcrawl backend. Use for: refreshing issue clusters, searching issues semantically, checking repo pulse, managing notifications, building/running the app, and coordinating ghcrawl data pipelines.