skillshare-changelog
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 (tests, changelog, release notes, version bump, announcements), use /release instead.
Best use case
skillshare-changelog is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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 (tests, changelog, release notes, version bump, announcements), use /release instead.
Teams using skillshare-changelog should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/skillshare-changelog/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How skillshare-changelog Compares
| Feature / Agent | skillshare-changelog | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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 (tests, changelog, release notes, version bump, announcements), use /release instead.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., `v0.16.0`) or omit to auto-detect via `git describe --tags --abbrev=0`.
**Scope**: This skill updates `CHANGELOG.md` and syncs the website changelog (`website/src/pages/changelog.md`). It does NOT generate RELEASE_NOTES, update version numbers, or handle the full release workflow — use `/release` for that.
## Workflow
### Step 1: Determine Version Range
```bash
# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
# Find previous tag
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")
echo "Generating changelog: $PREV_TAG → $LATEST_TAG"
```
### Step 2: Collect Commits
```bash
git log "${PREV_TAG}..${LATEST_TAG}" --oneline --no-merges
```
### Step 3: Categorize Changes
Group commits by conventional commit type:
| Prefix | Category |
|--------|----------|
| `feat` | New Features |
| `fix` | Bug Fixes |
| `refactor` | Refactoring |
| `docs` | Documentation |
| `perf` | Performance |
| `test` | Tests |
| `chore` | Maintenance |
### Step 4: Read Existing Entries for Style Reference
Before writing, read the most recent 2-3 entries in `CHANGELOG.md` to match the established tone and structure. The style evolves over time — always match the latest entries, not a hardcoded template.
### Step 5: Write User-Facing Entry
Write from the **user's perspective**. Only include changes users will notice or care about.
**Include**:
- New features with usage examples (CLI commands, code blocks)
- Bug fixes that affected user-visible behavior
- Breaking changes (renames, removed flags, scope changes)
- Performance improvements users would notice
**Exclude**:
- Internal test changes (smoke tests, test refactoring)
- Implementation details (error propagation, internal structs)
- Dev toolchain changes (Makefile cleanup, CI tweaks)
- Pure documentation adjustments
**Wording guidelines**:
- Don't use "first-class", "recommended" for non-default options
- Be factual: "Added X" / "Fixed Y" / "Renamed A to B"
- Include CLI example when introducing a new feature
- Use em-dash (`—`) to separate feature name from description
- Group related features under `####` sub-headings when there are 2+ distinct areas
### Step 6: Update CHANGELOG.md
Read existing `CHANGELOG.md` and insert new entry at the top, after the header. Match the style of the most recent entries exactly.
Structural conventions (based on actual entries):
```markdown
## [X.Y.Z] - YYYY-MM-DD
### New Features
#### Feature Area Name
- **Feature name** — description with `inline code` for commands and flags
```bash
skillshare command --flag # usage example
```
Additional context as sub-bullets or continuation text
#### Another Feature Area
- **Feature name** — description
### Bug Fixes
- Fixed specific user-visible behavior — with context on what changed
- Fixed another issue
### Performance
- **Improvement name** — description of what got faster
### Breaking Changes
- Renamed `old-name` to `new-name`
```
Key style points:
- Version numbers use `[X.Y.Z]` without `v` prefix in the heading
- Feature bullets use `**bold name** — em-dash description` format
- Code blocks use `bash` language tag for CLI examples
- Bug fixes describe the symptom, not the implementation
- Only include sections that have content (skip empty Performance, Breaking Changes, etc.)
### Step 7: Sync Website Changelog
The website has its own changelog page at `website/src/pages/changelog.md`. After updating `CHANGELOG.md`, sync the new entry to the website version.
**Differences between the two files**:
- Website file has MDX frontmatter (`title`, `description`) and an intro paragraph — preserve these, don't overwrite
- Website file has a `---` separator after the intro, before the first version entry
- The release entries themselves are identical in content
**How to sync**: Read the website changelog, then insert the same new entry after the `---` separator (line after intro paragraph), before the first existing version entry. Do NOT replace the entire file — only insert the new entry block.
## Rules
- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs or references
- **Verify features exist** — grep source before claiming a feature was added
- **No internal noise** — exclude test-only, CI-only, or refactor-only changes
- **Conventional format** — follow existing CHANGELOG.md style exactly
- **Always sync both** — `CHANGELOG.md` and `website/src/pages/changelog.md` must have identical release entriesRelated Skills
skillshare
Manages and syncs AI CLI skills across 50+ tools from a single source. Use this skill whenever the user mentions "skillshare", runs skillshare commands, manages skills (install, update, uninstall, sync, audit, analyze, check, diff, search), or troubleshoots skill configuration (orphaned symlinks, broken targets, sync issues). Covers both global (~/.config/skillshare/) and project (.skillshare/) modes. Also use when: adding new AI tool targets (Claude, Cursor, Windsurf, etc.), setting target include/exclude filters or copy vs symlink mode, using backup/restore or trash recovery, piping skillshare output to scripts (--json), setting up CI/CD audit pipelines, or building/sharing skill hubs (hub index, hub add).
skillshare-update-docs
Update website docs to match recent code changes, cross-validating every flag against source. Use this skill whenever the user asks to: update documentation, sync docs with code, document a new flag or command, fix stale docs, or update the README. This skill covers all website/docs/ categories (commands, reference, understand, how-to, troubleshooting, getting-started) plus the built-in skill description and README. If you just implemented a feature and need to update docs, this is the skill to use. Never manually edit website docs without cross-validating flags against Go source first.
skillshare-ui-website-style
Skillshare frontend design system for the React dashboard (ui/) and Docusaurus website (website/). Use this skill whenever you: build or modify a dashboard page or component in ui/src/, style or layout website pages or custom CSS in website/, create new React components for the dashboard, add pages to the dashboard, fix visual bugs in either frontend, or need to know which design tokens, components, or patterns to use. This skill covers color tokens, typography, component API, page structure, accessibility, keyboard shortcuts, animations, and anti-patterns for both frontends. Even if the user just says "fix the styling" or "add a card", use this skill to ensure consistency.
skillshare-release
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.
skillshare-implement-feature
Implement a feature from a spec file or description using TDD workflow. Use this skill whenever the user asks to: add a new CLI command, implement a feature from a spec, build new functionality, add a flag, create a new internal package, or write Go code for skillshare. This skill enforces test-first development, proper handler split conventions, oplog instrumentation, and dual-mode (global/project) patterns. If the request involves writing Go code and tests, use this skill — even if the user doesn't explicitly say "implement".
skillshare-devcontainer
Run CLI commands, tests, and debugging inside the skillshare devcontainer. Use this skill whenever you need to: execute skillshare CLI commands for verification, run Go tests (unit or integration), reproduce bugs, test new features, start the web UI, or perform any operation that requires a Linux environment. All CLI execution MUST happen inside the devcontainer — never run skillshare commands on the host. If you are about to use Bash to run `ss`, `skillshare`, `go test`, or `make test`, stop and use this skill first to ensure correct container execution.
skillshare-codebase-audit
Cross-validate CLI flags, docs, tests, and targets for consistency across the codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate targets.yaml, check handler split conventions, or verify oplog instrumentation. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect docs/code/tests have drifted out of sync.
skillshare-cli-e2e-test
Run isolated E2E tests in devcontainer from ai_docs/tests runbooks. Use this skill whenever the user asks to: run an E2E test, execute a test runbook, validate a feature end-to-end, create a new runbook, or test CLI behavior in isolation. If you need to run a multi-step CLI validation sequence (init → install → sync → verify), this is the skill — it handles ssenv isolation, flag verification, and structured reporting. Prefer this over ad-hoc docker exec sequences for any test that follows a runbook or needs reproducible isolation.
changelog-automation
Automate changelog generation from commits, PRs, and releases following Keep a Changelog format. Use when setting up release workflows, generating release notes, or standardizing commit conventions.
generating-changelog
Generates polished website release notes between two git tags for docs.streamlit.io. Use when preparing a new Streamlit release or reviewing changes between versions.
wiki-changelog
Generate structured changelogs from git history. Use when user asks "what changed recently", "generate a changelog", "summarize commits" or user wants to understand recent development activity.
app-store-changelog
Generate user-facing App Store release notes from git history since the last tag.