sparc-methodology
SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) comprehensive development methodology with multi-agent orchestration
Install with Tessl CLI
npx tessl i github:ruvnet/agentic-flow --skill sparc-methodology32
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
7%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 relies heavily on an unexplained acronym and abstract methodology terminology without describing concrete actions or providing trigger guidance. It fails to help Claude understand when to select this skill over others, and users searching for development planning or task breakdown help wouldn't naturally use these terms.
Suggestions
Add a 'Use when...' clause with natural trigger terms like 'plan a project', 'break down a complex task', 'design system architecture', or 'development workflow'
Replace abstract methodology phases with concrete actions Claude performs, e.g., 'Breaks complex development tasks into specifications, designs architecture, and coordinates implementation steps'
Explain what 'multi-agent orchestration' means in practical terms - what does Claude actually do with this capability?
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses abstract methodology terms (Specification, Pseudocode, Architecture, Refinement, Completion) but doesn't describe concrete actions Claude would perform. 'Multi-agent orchestration' is vague jargon without explaining what it actually does. | 1 / 3 |
Completeness | Only partially addresses 'what' through abstract methodology phases, and completely missing 'when' guidance. No 'Use when...' clause or equivalent trigger guidance exists. | 1 / 3 |
Trigger Term Quality | Contains technical jargon ('SPARC', 'multi-agent orchestration') that users would rarely naturally say. Missing common terms users might use like 'plan project', 'design system', 'break down task', or 'development workflow'. | 1 / 3 |
Distinctiveness Conflict Risk | The SPARC acronym and 'multi-agent orchestration' provide some distinctiveness, but 'comprehensive development methodology' is generic enough to potentially conflict with other coding/development skills. | 2 / 3 |
Total | 5 / 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 extremely comprehensive but suffers from severe verbosity, explaining many concepts Claude already understands (TDD cycles, microservices patterns, what code review is). The content would be far more effective at 20% of its current length with proper progressive disclosure to separate reference files. While it provides concrete examples, the lack of validation checkpoints in workflows and the monolithic structure significantly reduce its utility.
Suggestions
Reduce content by 80% - remove explanations of concepts Claude knows (TDD, microservices, what testing is) and keep only the specific tool syntax and project-specific conventions
Split into multiple files: SKILL.md (overview + quick reference), MODES.md (detailed mode descriptions), WORKFLOWS.md (orchestration patterns), EXAMPLES.md (integration examples)
Add explicit validation checkpoints to workflows, e.g., 'Verify swarm initialized successfully before spawning agents' and 'Confirm test failure before implementing code'
Convert pseudocode MCP calls to actual executable syntax or clarify that the syntax shown is illustrative - current format like 'mcp__claude-flow__sparc_mode { mode: "coder" }' is not valid JavaScript
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at 800+ lines with extensive repetition. Explains concepts Claude already knows (what TDD is, what microservices are, basic testing concepts). Many sections could be condensed to 10% of their current size while preserving all actionable information. | 1 / 3 |
Actionability | Provides concrete code examples and commands that are copy-paste ready, but many examples are pseudocode-like JavaScript objects rather than actual executable code. The MCP tool calls use a non-standard syntax that may not be directly executable. | 2 / 3 |
Workflow Clarity | Multi-step workflows are listed but lack explicit validation checkpoints. For example, the TDD workflow shows steps but doesn't include verification that tests actually fail/pass before proceeding. No feedback loops for error recovery in complex orchestration patterns. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content is inline despite being 800+ lines. The Table of Contents suggests structure but everything is in one massive document. Content like 'Available Modes' detailed descriptions should be in separate reference files. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (1116 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- 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.