agent-release-manager
Agent skill for release-manager - invoke with $agent-release-manager
40
13%
Does it follow best practices?
Impact
78%
2.51xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/agent-release-manager/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 description is critically deficient across all dimensions. It provides no information about what the skill does, when it should be used, or what triggers should activate it. It reads more like a label than a description, making it nearly useless for skill selection among multiple options.
Suggestions
Add concrete actions the skill performs, e.g., 'Creates release branches, generates changelogs, bumps version numbers, tags releases, and manages deployment workflows.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about cutting a release, creating a changelog, bumping versions, tagging a release, or managing deployment pipelines.'
Remove the invocation syntax from the description (it's metadata, not a capability description) and replace with domain-specific keywords users would naturally use like 'release', 'version', 'changelog', 'deploy', 'tag'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description contains no concrete actions whatsoever. It only says 'Agent skill for release-manager' which is entirely vague about what the skill actually does. | 1 / 3 |
Completeness | Neither 'what does this do' nor 'when should Claude use it' is answered. There is no description of capabilities and no 'Use when...' clause or equivalent trigger guidance. | 1 / 3 |
Trigger Term Quality | The only keyword is 'release-manager' which is somewhat relevant but there are no natural user terms like 'release', 'deploy', 'version bump', 'changelog', 'tag', etc. The invocation syntax '$agent-release-manager' is technical jargon, not a natural trigger. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so vague that it's impossible to distinguish it from any other agent or release-related skill. 'Release-manager' alone provides minimal differentiation without specifying what kind of releases, what actions, or what context. | 1 / 3 |
Total | 4 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is excessively verbose and repo-specific, reading more like a release log for a particular project (ruv-FANN v1.0.72) than a reusable skill. It mixes abstract strategy definitions Claude already understands with hardcoded examples that aren't generalizable. The content would benefit enormously from being split into a concise overview with references to template files, and from replacing the specific version/repo details with parameterized placeholders.
Suggestions
Reduce the skill to under 80 lines by extracting PR body templates, GitHub Actions YAML, and changelog templates into separate referenced files (e.g., TEMPLATES.md, CI_CD.md)
Remove abstract strategy objects (versionStrategy, validationStages, rollbackPlan) and the Best Practices/Monitoring sections — these describe concepts Claude already knows
Replace hardcoded repo names (ruvnet/ruv-FANN) and version numbers (v1.0.72) with parameterized placeholders to make the skill generalizable
Add explicit validation gates (e.g., 'If tests fail, STOP and report errors before creating PR') and concrete rollback commands instead of abstract rollback strategy objects
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~250+ lines with massive inline PR body templates, repeated version numbers, hardcoded repo-specific details (ruvnet/ruv-FANN), and conceptual explanations like semantic versioning definitions and strategy objects that Claude already knows. The release strategies section is entirely abstract JSON objects that add no actionable value. | 1 / 3 |
Actionability | Contains concrete tool invocations and bash commands, but much of the code is pseudocode-like JavaScript that isn't directly executable (e.g., JSON.stringify in MCP tool calls, `Date.now()` in memory_usage). The examples are heavily tied to a specific repo and version (v1.0.72) making them templates rather than generalizable instructions. Many paths use '$' instead of '/' suggesting corruption or placeholder issues. | 2 / 3 |
Workflow Clarity | The batch release workflow shows a sequential pipeline with TodoWrite tracking, but validation checkpoints are weak — tests are run but there's no explicit 'stop if tests fail' gate or error recovery loop. The rollback strategy section is entirely abstract with no concrete commands for actually performing a rollback. | 2 / 3 |
Progressive Disclosure | Monolithic wall of content with no references to external files. Everything is inlined including massive PR body templates, GitHub Actions YAML, strategy definitions, and best practices. Content that should be in separate reference files (PR templates, CI/CD configs, changelog templates) bloats the main skill file significantly. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- ruvnet/ruflo
- Commit
844f68d
- Reviewed
Table of Contents
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.