From ee526faeda0a8b58c32ab1ed078ff4f2b96b2748 Mon Sep 17 00:00:00 2001 From: Georgios Chatoutsidis Date: Fri, 17 Apr 2026 05:50:15 +0300 Subject: [PATCH] Add version candidate skill for release tagging process --- .github/skills/version-candidate/SKILL.md | 36 +++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 .github/skills/version-candidate/SKILL.md diff --git a/.github/skills/version-candidate/SKILL.md b/.github/skills/version-candidate/SKILL.md new file mode 100644 index 0000000..b46ed29 --- /dev/null +++ b/.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 ..HEAD` and `git log --oneline ..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. \ No newline at end of file