Add version candidate skill for release tagging process

.github/skills/version-candidate/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: version-candidate
+description: 'Generate the next release tag candidate from repo history, scope, and recent changes. Use when choosing a patch, minor, or major version for a new semver tag.'
+argument-hint: 'What version should we use for the next tag?'
+---
+
+# Version Candidate
+
+## When to Use
+- Choose the next tag version after changes land in the repository.
+- Compare the current branch against the last release tag.
+- Decide whether the release is a patch, minor, or major bump.
+- Keep the tag format consistent with existing repository tags.
+
+## Procedure
+1. Find the latest release tag with `git tag --sort=-v:refname`.
+2. Inspect the delta from that tag to `HEAD` with `git diff --stat <tag>..HEAD` and `git log --oneline <tag>..HEAD`.
+3. Classify the changes.
+	- Patch: bug fixes, tests, docs, CI, internal cleanup, or non-breaking refactors.
+	- Minor: additive public API, new module, or new behavior that does not break existing callers.
+	- Major: breaking API, removal, incompatible format change, or a scope reset.
+4. Check repo-specific versioning signals.
+	- Use `Package.swift`, `README.md`, and any SRS or release docs.
+	- Preserve the existing tag style; if the repository uses bare semver tags, do not add a `v` prefix.
+5. Pick the candidate version.
+	- Prefer the highest bump justified by the committed changes.
+	- If the branch adds a new public feature, do not collapse it into a patch release.
+6. Report the result.
+	- State the candidate version.
+	- Briefly explain the dominant change type that drove the choice.
+	- Call out any ambiguity if the version could reasonably be either of two adjacent bumps.
+
+## Completion Check
+- The candidate matches the repository's tag style.
+- The rationale names the last tag and the dominant change class.
+- If the release boundary is unclear, ask the user to choose between the two plausible versions.