skillshare-release

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 CHAN...