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:
parent
09803a75b7
commit
7fb69a5ca2
3
.pi/settings.json
Normal file
3
.pi/settings.json
Normal file
@ -0,0 +1,3 @@
|
||||
{
|
||||
"skills": ["skills"]
|
||||
}
|
||||
@ -17,14 +17,34 @@ Cut a release, validate the changelog, and ensure git hooks are installed.
|
||||
When the user triggers `/release <version>`:
|
||||
|
||||
1. **Install hooks** — run `scripts/install-hooks.sh` (idempotent)
|
||||
2. **Validate changelog** — confirm `## [Unreleased]` has content
|
||||
3. **Preview** — show the user what will be released (unreleased content + minor series rollup via `scripts/extract-changelog.sh`)
|
||||
4. **Ask for confirmation** — do NOT proceed without explicit user approval
|
||||
5. **Run `scripts/release.sh <version>`** — renames `[Unreleased]`, bumps version, commits, tags
|
||||
6. **Remind** — tell the user to `git push origin main --tags`
|
||||
2. **Check for unstaged work** — run `git status`. If there are valuable
|
||||
unstaged/uncommitted changes that belong in this release, commit them
|
||||
first (use the commit skill or make well-formed commits directly).
|
||||
3. **Validate changelog** — check if `## [Unreleased]` has content.
|
||||
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.
|
||||
|
||||
### 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
|
||||
|
||||
The changelog lives in `CHANGELOG.md` and follows [Keep a Changelog](https://keepachangelog.com/) conventions.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user