project

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:

1. Understand what changed

   • Review recent work (git diff, conversation context)
   • Summarize in user-facing terms (not implementation details)

2. 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

3. 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:

1. Check for unreleased changes

   • Read CHANGELOG.md
   • If no unreleased entries, inform user and stop

2. Determine version

   • Ask user for version number, or
   • Suggest based on changes (major/minor/patch)

3. Update changelog

   • Move "Unreleased" content to new version section
   • Add today's date
   • Reset "Unreleased" section (empty or with category headers)

4. 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