Create Release

An interactive workflow for creating releases of the LDAP-to-REST project.

Step 1: Authorization Check

1. •Run gh auth status and parse the logged-in username
2. •Check against the authorized users list: lukelabonte
3. •If not authorized: print a message explaining only authorized maintainers can create releases, then stop
4. •If gh is not authenticated: print a message to run gh auth login first, then stop

Step 2: Pre-flight Checks

Run these checks and report any failures:

1. •Clean working tree: git status --porcelain must return empty
2. •On main branch: git branch --show-current must return main
3. •Up-to-date with remote: git fetch origin main && git rev-list HEAD..origin/main --count must return 0

If any check fails, use AskUserQuestion explaining what's wrong with options:

• •Fix it — Provide instructions for the specific issue
• •Abort — Cancel the release

Step 3: Gather Changes Since Last Release

1. •Get last tag: git tag -l 'v*' --sort=-v:refname | head -1
2. •If no tags exist (first release): use git log --oneline for all commits
3. •Otherwise: git log --oneline <last_tag>..HEAD
4. •Also get the full diff summary: git diff --stat <last_tag>..HEAD (or from root if first release)
5. •Count and categorize commits — display a summary to the user

Step 4: Suggest Version Number

Analyze commit messages for patterns:

• •"fix", "bug", "patch" → suggest patch bump
• •"feat", "add", "new" → suggest minor bump
• •"breaking", "remove", "BREAKING CHANGE" → suggest major bump
• •If first release: suggest v1.0.0

Present via AskUserQuestion with the suggestion as recommended and alternatives available. Show the reasoning: "Found X features, Y fixes, Z breaking changes → suggesting vX.Y.Z"

Step 5: Curate Release Notes (Interactive)

Group commits into categories: Features, Fixes, Changes, Documentation, Internal

For each commit, decide if it's:

• •Clearly public-facing (new endpoints, bug fixes, config changes): Auto-include, show user for confirmation
• •Clearly internal (refactoring, CI, tests, CLAUDE.md changes): Auto-exclude, skip silently
• •Borderline (dependency updates, security fixes, performance): Ask via AskUserQuestion with:
  • •The commit message and what changed
  • •Why it might be worth including (user impact)
  • •Why it might be worth excluding (implementation detail)
  • •Recommended choice

Show progress throughout: "Release note X of Y"

After each included item, let user refine the wording if they want.

Step 6: Review Final Release Notes

Present the complete categorized release notes.

Use AskUserQuestion:

• •Looks good, proceed (Recommended)
• •Edit an entry — Ask which entry and what the new text should be
• •Add something manually — Let user add a custom entry
• •Start over — Redo from Step 5

Loop until user approves.

Step 7: Update CHANGELOG.md

1. •Read current CHANGELOG.md
2. •Under the ## [Unreleased] heading, insert a new version entry:

## [vX.Y.Z] - YYYY-MM-DD

### Added
- ...

### Fixed
- ...

### Changed
- ...

1. •Clear the [Unreleased] section content (leave the heading)
2. •Show the user the CHANGELOG diff for confirmation

Refer to references/changelog-format.md for formatting rules.

Step 8: Commit Changelog

Stage and commit the changelog update:

git add CHANGELOG.md

Then commit with message: Release vX.Y.Z

Use the HEREDOC format for the commit message.

Step 9: Create and Push Tag

Use AskUserQuestion:

• •Create tag and push (triggers release) (Recommended) — This will push the changelog commit and tag, triggering the release workflow
• •Abort — I changed my mind — Stop here without pushing

If proceeding:

git push origin main && git tag vX.Y.Z && git push origin vX.Y.Z

Tell the user: "Tag pushed. The release workflow is now running — it will build the Docker image, push to ghcr.io, and create the GitHub Release."

Step 10: Update GitHub Release with Curated Notes

1. •Wait a moment for the release to be created by the workflow
2. •Use WebFetch to load https://github.com/lukelabonte/LDAP-to-REST/releases and review the formatting of existing releases for consistency
3. •Build the release body: Docker pull command at the top (docker pull ghcr.io/lukelabonte/ldap-to-rest:X.Y.Z), then curated notes, then a link to the CHANGELOG section — match the style of existing releases
4. •Update the release: gh release edit vX.Y.Z --notes "..." (using HEREDOC)
5. •Confirm: "Release vX.Y.Z is live at https://github.com/lukelabonte/LDAP-to-REST/releases/tag/vX.Y.Z"

Important Notes

• •The .NET 8 SDK path must be set before any dotnet commands: PATH="/opt/homebrew/opt/dotnet@8/bin:$PATH"
• •The release workflow (.github/workflows/release.yml) triggers on v* tag push
• •The workflow builds, tests, pushes a Docker image to ghcr.io, and creates a GitHub Release with a placeholder body
• •This skill replaces the placeholder body with curated release notes