Преглед изворни кода

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
Tobi Lutke пре 3 месеци
родитељ
комит
7fb69a5ca2
2 измењених фајлова са 28 додато и 5 уклоњено
  1. 3 0
      .pi/settings.json
  2. 25 5
      skills/release/SKILL.md

+ 3 - 0
.pi/settings.json

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

+ 25 - 5
skills/release/SKILL.md

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