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/runkids/skillshare/skillshare-releasenpx skills add runkids/skillshare --skill skillshare-releasegit clone --depth 1 https://github.com/runkids/skillshareWhat 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.00087 | $0.01198 |
| Opus 5 | $0.00044 | $0.00599 |
| Sonnet 5 | $0.00017 | $0.00240 |
| Haiku 4.5 | $0.00009 | $0.00120 |
Grade A, and why
skillshare-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 — 132 lines — stays where its author put it; the contents beside it link to each section on GitHub.
End-to-end release workflow for skillshare. $ARGUMENTS specifies the version (e.g., v0.19.0).
Prerequisites
- All feature work merged to current branch
- Working directory clean (
git statusshows no uncommitted changes)
Workflow
Phase 1: Validate
Run full test suite and code quality checks. Fix any failures before proceeding.
make check # fmt-check + lint + test (builds binary first)
If tests fail: fix them, don't skip. Do not ask the user — fix and re-run.
Phase 2: Changelog
Invoke /changelog $VERSION to generate the changelog entry.
This handles:
- Collecting commits since last tag
- Categorizing by conventional commit type
- Writing user-facing CHANGELOG.md entry
- Syncing website changelog (
website/src/pages/changelog.md)
Review the output before proceeding.
Phase 3: Release Notes Draft (Maintainer Only, Local by Default)
Check if running as maintainer:
git config user.name # Should match "Willie" or maintainer identity
If maintainer:
Read the most recent specs/RELEASE_NOTES_*.md as a style reference, then generate specs/RELEASE_NOTES_<version>.md (no v prefix, e.g., RELEASE_NOTES_0.19.0.md).
Release notes are a local maintainer artifact by default. The specs/ directory is gitignored; do not force-add or commit specs/RELEASE_NOTES_<version>.md unless the user explicitly asks for release notes to be committed.
Structure:
- Title:
# skillshare vX.Y.Z Release Notes - TL;DR section with numbered highlights
- One
##section per feature/fix — describe what changed in plain language, with a CLI example or code block if relevant - Include migration guide if breaking changes exist
Wording rules (same user-facing standard as CHANGELOG):
- Describe what changed from the user's perspective, not how the code changed
- Never mention: function names, variable names, struct fields, file paths, Go syntax, internal APIs
- ✅ Good: "Sync now auto-creates missing target directories and shows what it did"
- ❌ Bad: "upgraded
Server.mufromsync.Mutextosync.RWMutexand applied a snapshot pattern across 30 handlers" - Keep it concise — a short paragraph per feature is enough
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 · 132 lines · 87 tokens per session scan A 36bc565a64fc
skillshare-release is a skill published in the GitHub repository runkids/skillshare (2,607 stars, last pushed 6d ago), licensed MIT. It adds 87 tokens to every session and 1,198 once invoked, about $0.0004 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
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…
obsidian-ops
Operations, syncing, versioning, and release management for Obsidian projects. Load when running builds, syncing references, bumping versions, or preparing for release.
ship
Commit and push changes with a pre-launch gate (validate-code + safe-repo) by default. --fast skips the gate.
shipping-and-launch
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
shipping-and-launch
准备生产发布。用于准备部署到生产环境时；用于需要发布前检查清单、设置监控、规划分阶段发布，或需要回滚策略时。.
production-deployment
Zero-downtime deployments with pre-flight checks, staged rollouts, and rollback plans. Never ship to production without a verified rollback strategy.