feat: release skill with changelog-driven workflow and git hooks

- Add /release skill with full process: hook install, changelog
  validation, git history review, preview, and release execution
- Skill auto-populates [Unreleased] from git history when empty
- Install hook script symlinks pre-push for tag validation
- Register skills/ dir in .pi/settings.json for pi discovery
This commit is contained in:
Tobi Lutke 2026-02-16 08:46:10 -04:00
parent 09803a75b7
commit 7fb69a5ca2
No known key found for this signature in database
2 changed files with 28 additions and 5 deletions

3
.pi/settings.json Normal file
View File

@ -0,0 +1,3 @@
{
"skills": ["skills"]
}

View File

@ -17,14 +17,34 @@ Cut a release, validate the changelog, and ensure git hooks are installed.
When the user triggers `/release <version>`: When the user triggers `/release <version>`:
1. **Install hooks** — run `scripts/install-hooks.sh` (idempotent) 1. **Install hooks** — run `scripts/install-hooks.sh` (idempotent)
2. **Validate changelog** — confirm `## [Unreleased]` has content 2. **Check for unstaged work** — run `git status`. If there are valuable
3. **Preview** — show the user what will be released (unreleased content + minor series rollup via `scripts/extract-changelog.sh`) unstaged/uncommitted changes that belong in this release, commit them
4. **Ask for confirmation** — do NOT proceed without explicit user approval first (use the commit skill or make well-formed commits directly).
5. **Run `scripts/release.sh <version>`** — renames `[Unreleased]`, bumps version, commits, tags 3. **Validate changelog** — check if `## [Unreleased]` has content.
6. **Remind** — tell the user to `git push origin main --tags` If empty or missing, **write the changelog now** (see below).
4. **Preview** — show the user what will be released (unreleased content +
minor series rollup via `scripts/extract-changelog.sh`)
5. **Ask for confirmation** — do NOT proceed without explicit user approval
6. **Run `scripts/release.sh <version>`** — renames `[Unreleased]`, bumps
version, commits, tags
7. **Remind** — tell the user to `git push origin main --tags`
If any step fails, stop and explain. Never force-push or skip validation. If any step fails, stop and explain. Never force-push or skip validation.
### Writing the changelog from git history
If `[Unreleased]` is empty when the release is triggered, populate it before
continuing:
1. Find the last release tag: `git describe --tags --abbrev=0`
2. Review commits since then: `git log <tag>..HEAD --oneline`
3. Read the diffs for anything non-obvious: `git log <tag>..HEAD --stat`
4. Write changelog entries following the standard below — group by theme,
explain the why, include numbers, credit contributors.
5. Add optional prose highlights (1-4 sentences) if the release warrants it.
6. Write the entries into `## [Unreleased]` in CHANGELOG.md.
7. Commit the changelog update, then continue with the release.
## Changelog Standard ## Changelog Standard
The changelog lives in `CHANGELOG.md` and follows [Keep a Changelog](https://keepachangelog.com/) conventions. The changelog lives in `CHANGELOG.md` and follows [Keep a Changelog](https://keepachangelog.com/) conventions.