skillshare-release
End-to-end release workflow for skillshare. Runs tests, generates changelog (via /changelog), writes RELEASE_NOTES, updates version numbers, commits, and drafts announcements. Use when the user says "release", "prepare release", "cut a release", "release v0.19", or any request to publish a new version. For changelog-only tasks, use /changelog instead.
Best use case
skillshare-release is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
End-to-end release workflow for skillshare. Runs tests, generates changelog (via /changelog), writes RELEASE_NOTES, updates version numbers, commits, and drafts announcements. Use when the user says "release", "prepare release", "cut a release", "release v0.19", or any request to publish a new version. For changelog-only tasks, use /changelog instead.
Teams using skillshare-release should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/skillshare-release/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How skillshare-release Compares
| Feature / Agent | skillshare-release | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
End-to-end release workflow for skillshare. Runs tests, generates changelog (via /changelog), writes RELEASE_NOTES, updates version numbers, commits, and drafts announcements. Use when the user says "release", "prepare release", "cut a release", "release v0.19", or any request to publish a new version. For changelog-only tasks, use /changelog instead.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
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 status` shows no uncommitted changes) ## Workflow ### Phase 1: Validate Run full test suite and code quality checks. Fix any failures before proceeding. ```bash 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 (Maintainer Only) Check if running as maintainer: ```bash 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`). 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.mu` from `sync.Mutex` to `sync.RWMutex` and applied a snapshot pattern across 30 handlers" - Keep it concise — a short paragraph per feature is enough **If not maintainer**: Skip this phase. ### Phase 4: Version Bump Update the version in `skills/skillshare/SKILL.md` frontmatter: ```yaml metadata: version: vX.Y.Z ``` This ensures `skillshare upgrade --skill` detects the new version correctly. ### Phase 5: Commit & Tag ```bash git add -A git commit -m "chore: release vX.Y.Z" git tag vX.Y.Z ``` Do NOT push yet — wait for user confirmation. ### Phase 6: Draft Announcements Prepare two drafts for user review: 1. **GitHub Release Notes** — concise, user-facing summary suitable for the GitHub release page. Shorter than RELEASE_NOTES, highlight top 3-5 changes with one-liners. 2. **Social media post** — 2-3 sentences max, casual tone, mention the version and 1-2 headline features. No hashtag spam. **Tone**: short, direct. Don't oversell. The user will edit before posting. ### Phase 7: Present & Confirm Show the user: - [ ] Test results (pass/fail) - [ ] CHANGELOG.md diff - [ ] RELEASE_NOTES file (if generated) - [ ] Version bump diff - [ ] GitHub release draft - [ ] Social media draft Wait for user approval before pushing: ```bash git push origin HEAD --tags ``` ## Rules - **Fix, don't skip** — if tests fail, fix them before continuing - **User perspective** — all written output is for users, not developers - **Short drafts** — announcements default to concise; user will ask for more detail if needed - **No fabricated links** — never invent URLs or references - **Verify before claiming** — grep source before stating a feature exists - **Ask before push** — never push or publish without explicit user confirmation - **Commit message** — always `chore: release vX.Y.Z` - **No competitive references** — never mention competitor repos in commit messages or notes
Related Skills
skillshare
Manages and syncs AI CLI skills across 50+ tools from a single source. Use this skill whenever the user mentions "skillshare", runs skillshare commands, manages skills (install, update, uninstall, sync, audit, analyze, check, diff, search), or troubleshoots skill configuration (orphaned symlinks, broken targets, sync issues). Covers both global (~/.config/skillshare/) and project (.skillshare/) modes. Also use when: adding new AI tool targets (Claude, Cursor, Windsurf, etc.), setting target include/exclude filters or copy vs symlink mode, using backup/restore or trash recovery, piping skillshare output to scripts (--json), setting up CI/CD audit pipelines, or building/sharing skill hubs (hub index, hub add).
skillshare-update-docs
Update website docs to match recent code changes, cross-validating every flag against source. Use this skill whenever the user asks to: update documentation, sync docs with code, document a new flag or command, fix stale docs, or update the README. This skill covers all website/docs/ categories (commands, reference, understand, how-to, troubleshooting, getting-started) plus the built-in skill description and README. If you just implemented a feature and need to update docs, this is the skill to use. Never manually edit website docs without cross-validating flags against Go source first.
skillshare-ui-website-style
Skillshare frontend design system for the React dashboard (ui/) and Docusaurus website (website/). Use this skill whenever you: build or modify a dashboard page or component in ui/src/, style or layout website pages or custom CSS in website/, create new React components for the dashboard, add pages to the dashboard, fix visual bugs in either frontend, or need to know which design tokens, components, or patterns to use. This skill covers color tokens, typography, component API, page structure, accessibility, keyboard shortcuts, animations, and anti-patterns for both frontends. Even if the user just says "fix the styling" or "add a card", use this skill to ensure consistency.
skillshare-implement-feature
Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI command, implement a feature from a spec, build new functionality, add a flag, create a new internal package, or write Go code for skillshare. This skill enforces test-first development, proper handler split conventions, oplog instrumentation, and dual-mode (global/project) patterns. If the request involves writing Go code and tests, use this skill — even if the user doesn't explicitly say "implement".
skillshare-devcontainer
Run CLI commands, tests, and debugging inside the skillshare devcontainer. Use this skill whenever you need to: execute skillshare CLI commands for verification, run Go tests (unit or integration), reproduce bugs, test new features, start the web UI, or perform any operation that requires a Linux environment. All CLI execution MUST happen inside the devcontainer — never run skillshare commands on the host. If you are about to use Bash to run `ss`, `skillshare`, `go test`, or `make test`, stop and use this skill first to ensure correct container execution.
skillshare-codebase-audit
Cross-validate CLI flags, docs, tests, and targets for consistency across the codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate targets.yaml, check handler split conventions, or verify oplog instrumentation. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect docs/code/tests have drifted out of sync.
skillshare-cli-e2e-test
Run isolated E2E tests in devcontainer from ai_docs/tests runbooks. Use this skill whenever the user asks to: run an E2E test, execute a test runbook, validate a feature end-to-end, create a new runbook, or test CLI behavior in isolation. If you need to run a multi-step CLI validation sequence (init → install → sync → verify), this is the skill — it handles ssenv isolation, flag verification, and structured reporting. Prefer this over ad-hoc docker exec sequences for any test that follows a runbook or needs reproducible isolation.
skillshare-changelog
Generate CHANGELOG.md entry from recent commits in conventional format. Also syncs the website changelog page. Use this skill whenever the user asks to: generate a changelog, document what changed between tags, or create a new CHANGELOG entry. If you see requests like "write the changelog for v0.17", "what changed since last release", this is the skill to use. Do NOT manually edit CHANGELOG.md without this skill — it ensures proper formatting, user-perspective writing, and website changelog sync. For full release workflows (tests, changelog, release notes, version bump, announcements), use /release instead.
SKILL: Azure Kusto Spark Connector — Release Process
## Identity
version-release
Version release workflow. Use when the user mentions 'release', 'hotfix', 'version upgrade', 'weekly release', or '发版'/'发布'/'小班车'. Provides guides for Minor Release and Patch Release workflows.
document-release
Post-ship documentation update. Reads all project docs, cross-references the diff, updates README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md to match what shipped, polishes CHANGELOG voice, cleans up TODOS, and optionally bumps VERSION. Use when asked to "update the docs", "sync documentation", or "post-ship docs". Proactively suggest after a PR is merged or code is shipped. (gstack)
claude-code-plugin-release
Automated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, and plugin.json, build verification, git tagging, GitHub releases, and changelog generation.