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 Draft (Maintainer Only, Local by Default) 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`). 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 wit...