Changelog Update Skill

Updates CHANGELOG.md with changes as they happen, not later.

When to Use

• •After completing a new feature
• •After fixing a bug
• •After changing existing behavior
• •Before committing completed work

When NOT to Use

• •Planning documents (_tasks/ folder)
• •Design docs, task plans, brainstorming notes
• •Internal documentation (CLAUDE.md, DECISIONS.md updates)
• •Tech debt tracking files
• •Any documentation that isn't user-visible

Rule: Changelog is for user-visible changes only. Planning and internal docs don't belong.

Changelog Sections (Slovak)

Workflow

1. Read Current Unreleased Section

head -20 CHANGELOG.md

2. Add Entry Under Correct Section

Edit CHANGELOG.md, adding entry under ## [Unreleased]:

## [Unreleased]

### Pridane
- {New feature description}

### Zmenene
- {Changed behavior description}

### Opravene
- {Bug fix description}

3. Create Section If Missing

If the needed section doesn't exist under [Unreleased], add it in this order:

1. •Pridane (Added)
2. •Zmenene (Changed)
3. •Opravene (Fixed)
4. •Odstranene (Removed)

4. Commit With Your Changes

Include changelog update in the same commit as the code change:

git add CHANGELOG.md src/...
git commit -m "feat: {description}"

Writing Good Entries

Do:

• •Write in Slovak
• •Be concise (one line per change)
• •Focus on user-visible impact
• •Use consistent terminology

Don't:

• •Include technical implementation details
• •Mention file names or internal refactoring
• •Write in English (except technical terms)

Examples

### Pridane
- Export do PDF s prehladom celej knihy jazd
- Moznost vymazat zalohy

### Zmenene
- Predvolene radenie: najnovsie zaznamy hore
- Zlepseny dizajn modalneho okna

### Opravene
- Oprava reaktivity dropdown-u pre vyber roku
- Autocomplete: oprava generovania tras pri uprave jazd

Notes

• •Update changelog IMMEDIATELY when completing work
• •Each commit can include a changelog update
• •Release skill (/release) moves [Unreleased] to versioned section
• •Write for users, not developers