Project Skill
Simple changelog management following Keep a Changelog conventions.
Sub-commands
/project log
Add an entry to the changelog after completing work.
Workflow:
- •
Understand what changed
- •Review recent work (git diff, conversation context)
- •Summarize in user-facing terms (not implementation details)
- •
Categorize the change
Category When to use Added New features Changed Changes to existing functionality Fixed Bug fixes Removed Removed features Security Security-related changes - •
Add to CHANGELOG.md
- •Create file if it doesn't exist
- •Add under "Unreleased" section in appropriate category
- •Keep entries concise (one line each)
Changelog format:
markdown
# Changelog All notable changes to this project. ## Unreleased ### Added - User authentication flow ### Fixed - Timezone bug in date picker --- ## v1.0.0 — 2026-01-15 ### Added - Initial release
/project release
Cut a new release by versioning unreleased changes.
Workflow:
- •
Check for unreleased changes
- •Read CHANGELOG.md
- •If no unreleased entries, inform user and stop
- •
Determine version
- •Ask user for version number, or
- •Suggest based on changes (major/minor/patch)
- •
Update changelog
- •Move "Unreleased" content to new version section
- •Add today's date
- •Reset "Unreleased" section (empty or with category headers)
- •
Optionally create git tag
- •Ask if user wants a git tag created
- •If yes:
git tag -a v{version} -m "Release v{version}"
File Convention
| File | Purpose |
|---|---|
CHANGELOG.md | Project changelog (root directory) |
Guidelines
- •Write for users, not developers (what changed, not how)
- •One entry per logical change
- •Link to issues/PRs if your project uses them:
Fixed login bug (#123) - •Don't log minor refactors or internal changes unless user-visible