菜单
Calculates next patch, minor, and major release versions following SemVer. Use this skill when you need to determine version_added values or answer questions about the next collection release version.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guides the release of an Ansible collection following the upstream process (without release branches). Automatically determines the next version from changelog fragments. Outputs step-by-step instructions with commands for changelog generation, release PR, tagging, Galaxy publication, version bump, and GitHub release. Use when asked to release, publish, or tag a new collection version.
Use this skill when you need to check backport and patchback workflow blockers for Ansible collection stable branches. Detects open backport PRs and patchback failures that must be resolved before creating a release prep PR. Complements version analysis skills by focusing on process blockers. By default, checks the two most recent stable branches.
Triage bug reports, CI failures, and GitHub issues across Ansible network collections (cisco.ios, cisco.iosxr, cisco.nxos, arista.eos, ansible.netcommon, ansible.utils, etc.). Two modes: scan mode for bulk weekly triage across all repos, and direct mode for deep triage of a single issue. Network-specific: uses cross-collection cascade detection for shared dependencies (netcommon, utils) and known network CI failure patterns. Outputs structured JSON and markdown. Use when asked to triage network issues, scan network issues, weekly triage, triage CI failure, or triage collection issue. Do not use for non-network collections or general Ansible questions.
Fetch Ansible documentation from docs.ansible.com as Markdown. Use when the user asks about an Ansible topic, references a docs.ansible.com URL, or when the agent needs to look up official Ansible documentation to complete a task or verify information.
Adds SonarCloud (SonarQube Cloud) static analysis to an Ansible collection repo: sonar-project.properties, GitHub Actions scanner workflow, XML coverage for Sonar, and contributor-facing docs; includes fork/secret and assistant-safe patterns (see Security section). Use when onboarding SonarCloud, wiring CI secrets, producing coverage.xml, or mirroring ansible-collections setups like amazon.aws.
Configures CI coverage reporting for SonarCloud on Ansible collections. Use this skill when Sonar already runs but coverage is missing and you need to wire XML reports, aggregator workflows, and scanner report paths.
| name | next-release |
| description | Calculates next patch, minor, and major release versions following SemVer. Use this skill when you need to determine version_added values or answer questions about the next collection release version. |
| user-invocable | true |
Calculate the next patch, minor, and major release versions following Semantic Versioning (SemVer).
This skill helps determine what version to use in version_added tags when documenting new features.
TRIGGER when:
version_added tagDO NOT TRIGGER when:
release skill instead)changelog-fragment skill instead)Use the current-release helper skill to fetch the current version.
This returns:
-dev0 stripped if present)Use hierarchical decision logic:
Note: If current-release reports a rebase warning (git version > galaxy.yml version), skip version calculations and proceed directly to Step 3 Case 1 for rebase guidance.
When current-release reports:
A.B.C (from galaxy.yml on main)X.Y.Z (where X < A, major version jumped)Calculate versions:
X.Y.(Z+1) (on stable branch X)X.(Y+1).0 (on stable branch X)A.B.C (current version on main, already in development)Example: Current 10.0.0-dev0 on main, stable-9 at 9.2.0
9.2.1 (on stable-9)9.3.0 (on stable-9)10.0.0 (on main)When no stable branch exists OR stable branch major version equals current major:
If status is IN DEVELOPMENT (X.Y.Z-dev0):
Current version IS the next release:
After release, calculate:
X.Y.(Z+1)X.(Y+1).0(X+1).0.0If status is RELEASED (X.Y.Z tag exists):
Calculate from the released version:
X.Y.(Z+1)X.(Y+1).0(X+1).0.0Use hierarchical decision logic with blocking conditions first:
When current-release reports a warning that git version > galaxy.yml version:
Current version: X.Y.Z (from galaxy.yml)
Stable branch version: A.B.C (higher version exists)
⚠️ BRANCH OUT OF DATE WARNING ⚠️
Version A.B.C has been released since this branch was created.
If intentional (backport/older branch work):
→ New features: Use version_added: "X.Y.Z" (acceptable for intentional older branch work)
→ Next minor: "X.(Y+1).0" (but this version may already be released!)
If unintentional:
→ Rebase this branch on latest stable or main
→ Update galaxy.yml to match current development version after rebase
→ Most PRs should be based on latest code
Confirm your intent before proceeding.
IMPORTANT: Do not proceed to Cases 2-4 if rebase warning is present. User must fix branch first.
When stable branch major < current major (and no rebase warning), check if current version is properly formatted:
If current is A.0.0 (proper major release):
Current version: A.0.0 (IN DEVELOPMENT on main - MAJOR RELEASE)
Stable branch version: X.Y.Z (stable-X)
For minor changes that will be backported:
→ Bugfixes: Use version_added: "X.Y.(Z+1)"
Merge to main first, then backport to stable-X for release as X.Y.(Z+1)
→ New features: Use version_added: "X.(Y+1).0"
Merge to main first, then backport to stable-X for release as X.(Y+1).0
→ Breaking changes: Use version_added: "A.0.0"
Cannot be backported - merge to main for release as A.0.0
Workflow: Merge to main → Backport to stable-X → Release from stable-X
The version_added tag should reflect where the feature will actually be released
(the backport version), not the main branch version.
If current is A.B.C where B>0 or C>0 (INCONSISTENCY):
⚠️ VERSION INCONSISTENCY WARNING ⚠️
Current version: A.B.C on main
Stable branch version: X.Y.Z (stable-X where X < A)
Main has jumped major version (X → A) but current version is A.B.C (not A.0.0).
This is inconsistent - major version bumps should always result in A.0.0.
Expected: A.0.0-dev0 in galaxy.yml on main
Actual: A.B.C-dev0 in galaxy.yml on main
→ Check galaxy.yml - should it be A.0.0-dev0 instead?
→ If this is a mistake, update galaxy.yml to A.0.0-dev0
Please fix the version in galaxy.yml before proceeding.
When status is IN DEVELOPMENT and no special cases above apply:
For major release (X.0.0-dev0):
Current version: X.0.0 (IN DEVELOPMENT - MAJOR RELEASE)
→ New features: Use version_added: "X.0.0"
→ Breaking changes: Use version_added: "X.0.0" (allowed in major releases)
For minor release (X.Y.0-dev0, Y≠0):
Current version: X.Y.0 (IN DEVELOPMENT - MINOR RELEASE)
→ New features: Use version_added: "X.Y.0"
→ Breaking changes: NOT ALLOWED - next major is (X+1).0.0
Coordinate with maintainers about when (X+1).0.0 development will begin.
For patch release (X.Y.Z-dev0, Z≠0):
Current version: X.Y.Z (IN DEVELOPMENT - PATCH RELEASE)
⚠️ SEMVER VIOLATION WARNING ⚠️
Patch releases can ONLY contain bugfixes per Semantic Versioning.
→ New features: NOT ALLOWED in patch releases
Features require a minor release. Should galaxy.yml be X.(Y+1).0-dev0 instead?
If you must add features now, use version_added: "X.(Y+1).0"
→ Breaking changes: NOT ALLOWED in patch releases
Breaking changes require a major release (X+1).0.0
Coordinate with maintainers about versioning strategy.
When status is RELEASED and no special cases apply:
Current version: X.Y.Z (RELEASED)
→ New features: Use version_added: "X.(Y+1).0" (next minor)
→ Breaking changes: Use version_added: "(X+1).0.0" (next major)
Coordinate with maintainers about when (X+1).0.0-dev0 development begins.
version_added tagsversion_added tagsExamples ordered by Step 3 case hierarchy:
User: "I'm adding a new parameter, what version should I use?"
current-release returns:
Current version: 9.1.0 (IN DEVELOPMENT, from galaxy.yml: 9.1.0-dev0)
Stable branch version: 9.2.0 (stable-9)
⚠️ WARNING: Version 9.2.0 appears to have been released since this branch was created.
Consider rebasing unless working on backport/older branch intentionally.
Response:
Current version: 9.1.0 (IN DEVELOPMENT - MINOR RELEASE)
⚠️ BRANCH OUT OF DATE WARNING ⚠️
Version 9.2.0 has been released since this branch was created.
If this is intentional (backport/older branch work):
→ New features: Use version_added: "9.1.0" (acceptable for intentional older branch work)
→ Next minor: "9.2.0" (but this version has already been released!)
If this is unintentional:
→ Consider rebasing this branch on the latest stable-9 or main
→ After rebase, galaxy.yml should be updated to match current development version
Most PRs should be based on the latest code. Confirm your intent before proceeding.
User: "I'm adding a new parameter, what version should I use?"
current-release returns: 10.0.0 (IN DEVELOPMENT, from galaxy.yml: 10.0.0-dev0 on main)
Stable branch: stable-9 at 9.2.0
Response:
Current version: 10.0.0 (IN DEVELOPMENT on main - MAJOR RELEASE)
Stable branch version: 9.2.0 (stable-9)
For minor changes that will be backported:
→ Bugfixes: Use version_added: "9.2.1"
Merge to main first, then backport to stable-9 for release as 9.2.1
→ New features: Use version_added: "9.3.0"
Merge to main first, then backport to stable-9 for release as 9.3.0
→ Breaking changes: Use version_added: "10.0.0"
Cannot be backported - merge to main for release as 10.0.0
For your new parameter (a minor feature), use version_added: "9.3.0".
Workflow: Merge to main → Backport to stable-9 → Release from stable-9
User: "I'm adding a new feature, what version should I use?"
current-release returns: 10.1.0 (IN DEVELOPMENT, from galaxy.yml: 10.1.0-dev0 on main)
Stable branch: stable-9 at 9.2.0
Response:
⚠️ VERSION INCONSISTENCY WARNING ⚠️
Current version: 10.1.0 on main
Stable branch version: 9.2.0 (stable-9)
Main has jumped major version (9 → 10) but current version is 10.1.0 (not 10.0.0).
This is inconsistent - major version bumps should always result in 10.0.0.
Expected: 10.0.0-dev0 in galaxy.yml on main
Actual: 10.1.0-dev0 in galaxy.yml on main
→ Check galaxy.yml - should it be 10.0.0-dev0 instead?
→ If this is a mistake, update galaxy.yml to 10.0.0-dev0
Please fix the version in galaxy.yml before proceeding.
User: "I'm adding a new parameter, what version should I use?"
current-release returns: 12.0.0 (IN DEVELOPMENT, from galaxy.yml: 12.0.0-dev0)
Response:
Current version: 12.0.0 (IN DEVELOPMENT - MAJOR RELEASE)
→ New features: Use version_added: "12.0.0"
→ Breaking changes: Use version_added: "12.0.0" (allowed in major releases)
User: "I'm adding a new parameter, what version should I use?"
current-release returns: 12.1.3 (IN DEVELOPMENT, from galaxy.yml: 12.1.3-dev0)
Response:
Current version: 12.1.3 (IN DEVELOPMENT - PATCH RELEASE)
⚠️ SEMVER VIOLATION WARNING ⚠️
Patch releases can ONLY contain bugfixes per Semantic Versioning.
→ New features: NOT ALLOWED in patch releases
Features require a minor release. Should galaxy.yml be 12.2.0-dev0 instead?
If you must add features now, use version_added: "12.2.0"
→ Breaking changes: NOT ALLOWED in patch releases
Breaking changes require a major release (13.0.0)
Coordinate with maintainers about versioning strategy.
User: "I'm adding a new module option, what version should I use?"
current-release returns: 9.2.0 (RELEASED, from stable-9 + git tag)
Response:
Current version: 9.2.0 (RELEASED)
→ New features: Use version_added: "9.3.0" (next minor)
→ Breaking changes: Use version_added: "10.0.0" (next major)
Coordinate with maintainers about when 10.0.0-dev0 development begins.