release-versioning

How xberg versions are synced and released — Cargo.toml is the single source of truth, `task version:sync` propagates it to alef-managed binding manifests AND the integrations under integrations/, which are versioned and published in lockstep with core (including -rc.N). Load before bumping a version, editing the version-sync task, or touching an integration's version/xberg dependency.

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

90%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An excellent, dense, repo-specific instruction skill: fully actionable commands and identifiers, correct ordering, validation via version:check, and explicit do/don't guardrails. The two weaker spots are the implicit drift-recovery loop and the absence of any progressive-disclosure split despite ~68 lines of per-ecosystem versioning rules.

Suggestions

Add an explicit feedback loop to the workflow section: state that if `task version:check` fails on integration drift, run `task version:sync` and re-run the check before committing (and note that `alef sync-versions` drift must be verified separately since check does not dry-run it).

Consider moving the per-ecosystem dependency-pin rules (PEP 440 floor form for pyproject, `<xberg.version>` for Maven, exact npm pin) and the four target-family listing into a `references/pin-rules.md`, keeping SKILL.md as a sub-50-line overview with a clearly signaled one-level-deep reference.

Spell out the recovery path for a mistaken hand-edit: e.g. 'If a manifest version was hand-edited, discard the change and re-run `task version:sync` rather than fixing it manually' — currently the Don't section only implies this.

Dimension	Reasoning	Score
Conciseness	Lean and efficient — every line carries a non-obvious repo fact Claude cannot know (the three sync steps, PEP 440 floor-pin rationale, the unpublished llama-index aggregator caveat, alef's exclusion of integrations). No padding, no explanation of concepts Claude already knows; assumes competence throughout.	5 / 5
Actionability	Fully executable instruction-only guidance: exact commands (`task version:bump:major\|minor\|patch`, `task version:set -- <version>`, `task version:check`), exact file paths and config keys (`.task/tools/version-sync.yml`, `alef.toml [workspace.sync] extra_paths`, `plugin/.ai-rulez/config.toml [plugin].version`), and exact identifiers to edit (`VERSION_TARGETS`, `XBERG_DEP_MANIFESTS`, `NPM_MANIFESTS`) for extending the workflow.	5 / 5
Workflow Clarity	The three sync steps are numbered and explicitly ordered, and validation exists (`task version:check` "failing on integration drift", run in CI). However, the error-recovery feedback loop is implied rather than spelled out — the doc never says 'if check fails on drift, run `task version:sync` and re-check' — and the caveat that check "does not dry-run `alef sync-versions`" leaves a small blind spot in the checkpoint. This sits between anchor 4 (most checkpoints present) and anchor 5 (explicit feedback loops), closer to 4.	4 / 5
Progressive Disclosure	Well-organized sections with a clean overview flow and no nested/dead-end references — all file mentions are real repo paths, appropriately one level deep. However, at ~68 lines it exceeds the 'under 50 lines' simple-skill exception, and the dense per-ecosystem detail (PEP 440 vs native vs semver pin forms for each of the four target families) is content that could live in a `references/` file, which is exactly anchor 4's 'minor organization gaps' rather than a fully appropriate split.	4 / 5
	Total	18 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete, third-person, comprehensive on what the skill governs, with an explicit 'Load before…' trigger clause covering the main entry points. The only gap is that a few natural synonyms users might say (release/publish/chart bumping) are not covered, which slightly limits trigger recall.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete, specific actions with comprehensive coverage of the domain: "Cargo.toml is the single source of truth", "`task version:sync` propagates it to alef-managed binding manifests AND the integrations under integrations/", "versioned and published in lockstep with core (including -rc.N)". No vague or abstract language; it stays in third person ("How xberg versions are synced").	5 / 5
Completeness	Clearly answers both questions: the 'what' ("How xberg versions are synced and released — Cargo.toml is the single source of truth, `task version:sync` propagates it…") and an explicit 'when' clause with concrete trigger phrases ("Load before bumping a version, editing the version-sync task, or touching an integration's version/xberg dependency"). The explicit trigger guidance means the ≤3 cap for a missing 'Use when…' clause does not apply.	5 / 5
Trigger Term Quality	Good natural keyword coverage: "bumping a version", "editing the version-sync task", "touching an integration's version/xberg dependency", "synced and released" — phrases a user would plausibly say. A few natural variations are missing (e.g. "cut/publish a release", "bump the chart/Helm version", "update the dependency pin"), which keeps it below the comprehensive anchor 5 but comfortably above anchor 3's 'some relevant keywords'.	4 / 5
Distinctiveness Conflict Risk	Clear niche with distinct, repo-specific triggers (version syncing, release lockstep, alef-managed manifests, integration dependency pins). It is very unlikely to fire for the wrong skill; the triggers name exact tooling and paths.	5 / 5
	Total	19 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 3 missing	Warning

	Total	15 / 16 Passed

Repository: xberg-io/xberg
Path: .ai-rulez/skills/release-versioning/SKILL.md
Commit: fbf07e1

Reviewed: 13 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.