| name | skillshare-release |
| description | 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. |
| argument-hint | <version> |
| metadata | {"targets":["claude","universal"]} |
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.
make check
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:
git config user.name
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:
metadata:
version: vX.Y.Z
This ensures skillshare upgrade --skill detects the new version correctly.
Phase 5: Commit & Tag
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:
-
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.
-
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:
Wait for user approval before pushing:
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
