Menu
How versions are numbered and the changelog written. Invoke before cutting a version, writing a CHANGELOG entry, or drafting release notes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | deckle-versioning |
| description | How versions are numbered and the changelog written. Invoke before cutting a version, writing a CHANGELOG entry, or drafting release notes. |
| type | skill |
Decide which number to bump and what goes in the changelog.
Versions track user-facing change, not API compatibility. MAJOR is an overhaul, MINOR a real cycle (a feature, an engine change), PATCH a fix or small step. Stay in 0.x until the behaviour surface is stable enough to promise.
The changelog follows keepachangelog — six categories in order (Added, Changed, Deprecated, Removed, Fixed, Security), newest first, ISO date. It is generated from the Conventional-Commit history by scripts/lib/changelog.ps1 (the deckle.ps1 Release menu), with no external tool and no network: plain git log keeps the changelog as local and autonomous as the app itself. Types route to categories — feat→Added, fix→Fixed, perf/refactor→Changed, revert→Removed; housekeeping (chore/docs/test/ci/build/style), merges and non-conventional subjects are dropped, so a change surfaces only if its commit is written conventionally. The file is regenerated wholesale from the v0.4.0 floor forward and is not hand-edited; earlier history predates the discipline and is summarised, not itemised. A capability is announced Deprecated in a MINOR and only Removed in a MAJOR, never cold.
Release notes are the same generator's output: at publish time publish-app.ps1 calls changelog.ps1 -NotesFor <version> and feeds the result to gh release create --notes-file. No hand authoring, no GitHub auto-notes.
What to expose in settings surfaces and how to organize it. Invoke before exposing a setting, organizing a page, or reworking a settings surface.
Testing posture — test behavior not implementation, stay sober, grow coverage per workstream. Invoke before writing a test or extending coverage.
One normalized way to name files, folders, symbols, resources and providers. Invoke before naming or renaming.
How to write the JOURNAL.md. Invoke when recording a finding, or a small decision worth keeping.
What to observe in code, and how to write it readable and actionable. Invoke before adding or changing an observation point.
Commit grain and the few deviations from the universal convention. Invoke before committing, splitting a workstream into commits, or auditing history.
