Content
40%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is rich in concrete CLI/YAML examples but reads as an unstructured catalog: examples are not executable as written (broken "$" paths, pseudocode MCP calls, mismatched code fences), there is no end-to-end workflow with validation checkpoints, and progressive disclosure is absent — everything is inlined in one 640-line file while its only cross-references point to non-existent files. It needs consolidation into a short overview plus real reference files, and an actual step-by-step usage sequence.
Suggestions
Replace the pseudocode MCP sections ("mcp__claude-flow__swarm_init { ... }") with real, runnable tool invocations and fix the "$"-for-"/" path corruption (".github$workflows$swarm-ci.yml", "actions$checkout@v3", "dist$index.js") so examples are copy-paste executable.
Add an explicit multi-step workflow with validation checkpoints, e.g. 1) analyze repo and detect stack, 2) generate workflow, 3) validate YAML (actionlint) and dry-run, 4) only then commit/deploy — especially before automated operations like self-heal, auto-retry, and issue creation.
Split the ~640-line catalog into real reference files (workflow templates, MCP orchestration patterns, monitoring commands), keep SKILL.md as a concise overview with one-level-deep links, and remove or create the broken "See also" links to swarm-pr.md, swarm-issue.md, and sync-coordinator.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~640-line body is mostly command/YAML examples rather than explanations of known concepts, so it avoids the worst padding, but it repeats near-identical `npx ruv-swarm actions ...` example blocks across sections ("Action Commands", "Advanced Features", "Monitoring & Insights", "Advanced Swarm Workflow Automation") that could be consolidated. This fits anchor 3 ('mostly efficient but could be tightened') rather than 2, since each block is concrete and no background concepts are re-explained. | 3 / 5 |
Actionability | There is abundant concrete guidance (specific CLI flags, workflow YAML), but much of it is not executable as written: file paths use "$" instead of "/" (".github$workflows$swarm-ci.yml", "dist$index.js"), the MCP tool sections are pseudocode ("mcp__claude-flow__swarm_init { ... }" in bash blocks) rather than real invocations, GitHub Actions expressions like "${{ github.sha }}" appear inside plain bash blocks, and the action.yml YAML is fenced as ```javascript. This matches anchor 3 ('pseudocode instead of executable code; missing key details') rather than 4, where code would be copy-paste runnable. | 3 / 5 |
Workflow Clarity | The body is a catalog of disconnected snippets with no start-to-finish sequence for actually setting up workflow automation — no ordered steps (e.g. analyze repo → generate workflow → validate → deploy) and no validation checkpoints, despite covering risky automated operations (auto-retry, self-heal, auto-execute deploys, issue creation). This fits anchor 2 ('rough sequence present but many gaps; validation absent') better than 3, since not even a listed step sequence exists for the skill's core task. | 2 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), yet the body inlines ~640 lines of template catalogs that clearly belong in separate files, and its only external pointers — "See also: [swarm-pr.md](.$swarm-pr.md), [swarm-issue.md](.$swarm-issue.md), [sync-coordinator.md](.$sync-coordinator.md)" — reference files that do not exist (broken links with "$" for "/"). Anchor 2 ('content that clearly belongs in separate files is inlined') is the best fit; not 3 because the structure present is section headers over monolithic inline content with broken, non-functional references. | 2 / 5 |
Total | 10 / 20 Passed |