# Skillshare Changelog

Generate CHANGELOG.md entry from recent commits in conventional format.

- Repository: https://github.com/runkids/skillshare (2879 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add runkids/skillshare --skill skillshare-changelog -g -a claude-code -y`
Codex: `npx skills add runkids/skillshare --skill skillshare-changelog -g -a codex -y`
Cursor: `npx skills add runkids/skillshare --skill skillshare-changelog -g -a cursor -y`
Gemini CLI: `npx skills add runkids/skillshare --skill skillshare-changelog -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

```bash
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.

### Step 4: Read Existing Entries for Style Reference

The rest: https://github.com/runkids/skillshare/blob/HEAD/.skillshare/skills/skillshare-changelog/SKILL.md