Agent skill for release-swarm - invoke with $agent-release-swarm
39
6%
Does it follow best practices?
Impact
100%
2.94xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/agent-release-swarm/SKILL.mdQuality
Discovery
0%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an extremely weak description that provides virtually no useful information for skill selection. It only states the skill's name and invocation command without describing any capabilities, actions, or usage triggers. Claude would have no basis for choosing this skill appropriately from a set of available skills.
Suggestions
Add concrete actions describing what the release-swarm skill does (e.g., 'Coordinates multi-agent release workflows, manages version bumps, generates changelogs, and publishes packages').
Add an explicit 'Use when...' clause with natural trigger terms (e.g., 'Use when the user needs to create a release, publish a new version, coordinate a multi-step release process, or manage changelogs').
Remove the invocation instruction ('invoke with $agent-release-swarm') from the description field—this is operational detail, not selection criteria—and replace it with capability and trigger information.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description contains no concrete actions whatsoever. 'Agent skill for release-swarm' is entirely vague—it doesn't describe what the skill does, only that it exists. | 1 / 3 |
Completeness | The description fails to answer both 'what does this do' and 'when should Claude use it'. It only provides an invocation command, with no explanation of functionality or usage triggers. | 1 / 3 |
Trigger Term Quality | The only potentially relevant term is 'release-swarm', which is a technical/internal name rather than a natural keyword a user would say. There are no natural trigger terms like 'release', 'deploy', 'version', etc. | 1 / 3 |
Distinctiveness Conflict Risk | While 'release-swarm' is a unique name, the description is so vague that Claude cannot determine when to select it over other skills. Without knowing what it does, it could conflict with any release-related or agent-related skill. | 1 / 3 |
Total | 4 / 12 Passed |
Implementation
12%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is extremely verbose and reads more like a product brochure for `ruv-swarm` than actionable instructions for Claude. Nearly all commands depend on an undocumented CLI tool with no way to verify they work, and the content contains path syntax errors (using `$` instead of `/`). The sheer volume of repetitive examples with minor flag variations provides little incremental value while consuming enormous token budget.
Suggestions
Reduce content to under 100 lines by extracting configuration examples, integration examples, and the release notes template into separate referenced files.
Replace or supplement opaque `npx ruv-swarm` commands with verifiable, executable alternatives using standard tools (gh CLI, npm, docker) so Claude can actually execute the steps.
Fix path syntax errors throughout (e.g., `repos/:owner/:repo$compare` should use `/` not `$`, `actions$checkout@v3` should be `actions/checkout@v3`).
Add explicit validation checkpoints with error recovery instructions—e.g., 'If changelog generation fails, check X; if version bump conflicts, do Y'—rather than relying on `--block-on-failure` flags.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 400+ lines with massive amounts of repetitive CLI examples that are essentially variations of the same pattern (`npx ruv-swarm github <subcommand> --flags`). Includes unnecessary sections like release notes templates, best practices lists, and multiple integration examples that add little unique value. Much of this could be condensed to a fraction of the size. | 1 / 3 |
Actionability | Despite the volume of code blocks, nearly all commands reference `npx ruv-swarm` which is an undocumented proprietary tool—none of these commands are verifiably executable or copy-paste ready. The gh CLI snippets have syntax issues (e.g., `repos/:owner/:repo$compare` uses `$` instead of `/`), and the overall guidance reads more like aspirational marketing material than concrete, tested instructions. | 1 / 3 |
Workflow Clarity | The GitHub Actions workflow and the 'Standard Release Flow' section provide a reasonable sequence of steps. However, validation checkpoints are mostly delegated to opaque `npx ruv-swarm` commands with `--block-on-failure` flags rather than explicit feedback loops. There's no clear error recovery guidance—just 'rollback' commands without explaining how to diagnose what went wrong. | 2 / 3 |
Progressive Disclosure | The content is a monolithic wall of text with no meaningful separation into referenced files. It references `workflow-automation.md` and `multi-repo-swarm.md` at the very end, but no bundle files are provided. Massive sections like the YAML config, release notes template, and all the integration examples should be in separate files. The inline content is overwhelming and poorly organized for discovery. | 1 / 3 |
Total | 5 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (588 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
9d4a9ea
Table of Contents
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.