skillshare-release

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   # 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:

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:

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:

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:

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