name	release
description	Cut a new dais release — bump the semver tag (major\|minor\|patch), push it, and create the matching GitHub release. Use when the user runs /release or asks to cut/publish a release.

release

Cut a new release of dais by bumping the version tag and publishing a GitHub release.

The bump level is required. Invoke as /release major, /release minor, or /release patch. If no level (or an unrecognized one) is given, stop and ask which of major, minor, or patch to use — do not assume a default.

Releases follow the v-prefixed annotated-tag convention (e.g. v1.0.0 → v1.1.0). There is no version field anywhere in the source to edit — a release is purely tag → push → GitHub release.

Steps

Fetch tags first. Always start with git fetch --tags --force so the latest version is computed from what's actually on the remote, not a stale local view.
Find the latest version. Take the highest v-prefixed semver tag:
```
git tag --list 'v*' | sort -V | tail -1
```
If none exists, treat the baseline as v0.0.0. (A bare 1.0.0 tag without the v prefix predates this convention — ignore it for computing the next version.)
Compute the next version from the requested level, resetting lower components:
- major: vX.0.0 → v(X+1).0.0
- minor: vX.Y.0 → vX.(Y+1).0
- patch: vX.Y.Z → vX.Y.(Z+1)
Confirm before pushing. Show the user the current version, the computed new version, and what will happen (annotated tag → push → GitHub release). Wait for an explicit OK before doing anything that touches the remote.
Create the annotated tag on HEAD:
```
git tag -a vX.Y.Z -m "vX.Y.Z"
```
Push the tag:
```
git push origin vX.Y.Z
```
Create the GitHub release. The release is named with just the version, and notes are auto-generated by GitHub from the commits/PRs since the last tag:
```
gh release create vX.Y.Z --title vX.Y.Z --generate-notes
```
Fetch tags again so local state reflects the published release:
```
git fetch --tags --force
```
Report the new version and the release URL (printed by gh release create).

Notes

Run from a clean tree on the branch you intend to release. If git status is dirty or you're not on the expected branch, flag it before tagging.
If the tag already exists locally or remotely, stop and report — don't overwrite.

release

Cut a new release of dais by bumping the version tag and publishing a GitHub release.

Steps

Fetch tags first. Always start with git fetch --tags --force so the latest version is computed from what's actually on the remote, not a stale local view.

Find the latest version. Take the highest v-prefixed semver tag:

git tag --list 'v*' | sort -V | tail -1

If none exists, treat the baseline as v0.0.0. (A bare 1.0.0 tag without the v prefix predates this convention — ignore it for computing the next version.)

Compute the next version from the requested level, resetting lower components:

major: vX.0.0 → v(X+1).0.0
minor: vX.Y.0 → vX.(Y+1).0
patch: vX.Y.Z → vX.Y.(Z+1)

Confirm before pushing. Show the user the current version, the computed new version, and what will happen (annotated tag → push → GitHub release). Wait for an explicit OK before doing anything that touches the remote.

Create the annotated tag on HEAD:

git tag -a vX.Y.Z -m "vX.Y.Z"

Push the tag:

git push origin vX.Y.Z

Create the GitHub release. The release is named with just the version, and notes are auto-generated by GitHub from the commits/PRs since the last tag:

gh release create vX.Y.Z --title vX.Y.Z --generate-notes

Fetch tags again so local state reflects the published release:

git fetch --tags --force

Report the new version and the release URL (printed by gh release create).

Notes

Run from a clean tree on the branch you intend to release. If git status is dirty or you're not on the expected branch, flag it before tagging.

If the tag already exists locally or remotely, stop and report — don't overwrite.