| name | project |
| description | Manage project changelog. Use /project log after completing work, /project release when ready to ship. |
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:
# 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
