Skillshare Changelog
Generate CHANGELOG.md entry from recent commits in conventional format.
Install
npx skills add runkids/skillshare --skill skillshare-changelog -g -a claude-code -y- Repository
- runkids/skillshare2.9k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Lightabout 1,374 tokens
- Runs scripts
- No, instructions only
What it does
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 (Release PR review, tests, draft assets, publication, announcements), use /release instead.
Review or generate a user-facing changelog entry. Prefer the open Release Please PR and its manifest version for an upcoming release. For historical work, $ARGUMENTS specifies the requested tag or commit range.
Scope: This skill updates CHANGELOG.md and syncs the website changelog (website/src/pages/changelog.md). It does NOT generate RELEASE_NOTES, choose a new version, or handle the full release workflow, use /release for that.
Before acting, run python3 scripts/ai-context.py release. That topic is the source of truth for authorization, changelog content and synchronization rules; this skill retains the entry-generation workflow.
Workflow
Step 1: Determine Version Range
For an upcoming release, work on the Release PR branch and read .github/release-please-manifest.json. Verify the latest published tag and use its range to the Release PR head. Keep the proposed version; this skill does not authorize a version change. Tags may exist for unpublished drafts, so do not assume the highest local tag is the latest published release.
For historical work, use the user-requested tags or range.
Step 2: Collect Commits
git log <previous-published-tag>..<release-pr-head-or-requested-tag> --oneline --no-merges
Review the generated Release Please entry before writing. Preserve useful manual examples and migration notes. Do not add a second entry for the same version.
Step 3: Categorize Changes
Group commits by conventional commit type:
| Prefix | Category |
|---|---|
feat | New Features |
fix | Bug Fixes |
perf | Performance |
| breaking change | Breaking Changes and migration notes |
revert | Reverts, when user-visible |
Exclude test-only, CI-only, pure refactoring, documentation-only and internal maintenance entries from published notes.
