Add release skill for SemVer tagging workflow

Project-specific skill that validates version, checks for clean
working tree and pushed commits, then creates and pushes a SemVer
tag to trigger the CI/CD pipeline.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/skills/release/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: release
+description: Create a SemVer release tag and push it to trigger the CI/CD pipeline. Use this skill when the user says "release", "tag a release", "publish version X.Y.Z", "create a release", or mentions pushing a version tag. Also trigger when the user says "/release".
+---
+
+# Release
+
+Create a SemVer git tag and push it to the Gitea remote, triggering the CI/CD pipeline which builds and publishes a Docker image.
+
+## How it works
+
+The project uses a Gitea Actions pipeline (`.gitea/workflows/ci.yaml`) with three jobs:
+
+- **backend-test**: JDK 25, `./mvnw -B verify`
+- **frontend-test**: Node 24, lint + type-check + tests + build
+- **build-and-publish**: Docker image build + push (only on SemVer tags)
+
+When a tag matching `X.Y.Z` is pushed, `build-and-publish` runs after both test jobs pass. It publishes the Docker image to the Gitea container registry with four rolling tags: `X.Y.Z`, `X.Y`, `X`, and `latest`.
+
+## Arguments
+
+The user provides a version string as argument, e.g. `/release 0.2.0`. If no version is provided, ask for one.
+
+## Workflow
+
+Execute these steps in order. Stop and report if any check fails.
+
+### 1. Validate the version
+
+The argument must be a valid SemVer string: `X.Y.Z` where X, Y, Z are non-negative integers. Reject anything else (no `v` prefix, no pre-release suffixes).
+
+### 2. Check for existing tag
+
+Run `git tag -l <version>`. If the tag already exists locally or on the remote, stop and tell the user.
+
+### 3. Check working tree is clean
+
+Run `git status --porcelain`. If there is any output, stop and warn the user about uncommitted changes. List what's dirty.
+
+### 4. Check all commits are pushed
+
+Compare `git rev-parse HEAD` with `git rev-parse @{upstream}`. If they differ, stop and warn the user that there are unpushed local commits. Show `git log @{upstream}..HEAD --oneline` so they can see what's pending.
+
+### 5. Confirm with the user
+
+Before creating the tag, show a summary and ask for confirmation:
+- Version to tag: `<version>`
+- Commit being tagged: short hash + subject line
+- What will happen: pipeline runs tests, then builds and publishes `<registry>/<owner>/fete:<version>` (plus rolling tags)
+
+### 6. Create and push the tag
+
+```bash
+git tag <version>
+git push origin <version>
+```
+
+### 7. Report success
+
+Tell the user:
+- Tag `<version>` pushed successfully
+- The CI/CD pipeline is now running
+- They can watch the progress in the Gitea Actions UI
+- Once complete, the image will be available as `docker pull <registry>/<owner>/fete:<version>`
+
+Do not wait for the pipeline to finish or poll its status.