agent-implementer-sparc-coder
Agent skill for implementer-sparc-coder - invoke with $agent-implementer-sparc-coder
38
13%
Does it follow best practices?
Impact
69%
1.09xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/agent-implementer-sparc-coder/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 essentially non-functional as a skill selector. It provides only an invocation command and a cryptic name ('implementer-sparc-coder') with zero information about what the skill does, what domain it operates in, or when it should be selected. Claude would have no basis for choosing this skill over any other.
Suggestions
Describe the concrete actions this skill performs (e.g., 'Implements code modules following the SPARC methodology, generating structured implementations from specifications').
Add an explicit 'Use when...' clause with natural trigger terms users would say (e.g., 'Use when the user asks to implement code, build features, or write modules following SPARC principles').
Include domain-specific keywords that distinguish this from other coding skills (e.g., mention SPARC framework specifics, the types of code it generates, or the workflow it follows).
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description contains no concrete actions whatsoever. It only states it is an 'agent skill' with an invocation command, providing no information about what it actually does. | 1 / 3 |
Completeness | Neither 'what does this do' nor 'when should Claude use it' is answered. The description only provides an invocation command with no explanation of purpose or trigger conditions. | 1 / 3 |
Trigger Term Quality | There are no natural keywords a user would say. 'implementer-sparc-coder' is internal jargon/a tool name, not something a user would naturally request. No domain terms like 'code', 'implement', 'build', or 'develop' are present in a usable way. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so vague that it could conflict with any coding or implementation skill. There is nothing to distinguish it from other skills beyond its opaque name. | 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, spending most of its token budget teaching Claude generic software engineering concepts it already knows (TDD, SOLID, error handling patterns, dependency injection). The workflow has a reasonable structure but lacks concrete, executable guidance and proper validation checkpoints. The content would benefit enormously from being reduced to ~30% of its current size, focusing only on project-specific conventions and concrete tool usage.
Suggestions
Remove all generic software engineering explanations (TDD definition, SOLID, DRY, YAGNI, KISS, basic error handling patterns) — Claude already knows these concepts thoroughly.
Replace pseudocode workflow phases with actual tool invocations and concrete commands that Claude should execute, including specific validation checkpoints with error recovery steps.
Extract code patterns and documentation standards into separate reference files (e.g., PATTERNS.md, DOCS.md) and link to them from a concise overview in SKILL.md.
Add explicit feedback loops: what to do when tests fail unexpectedly, how to handle lint errors, and when to escalate or request clarification.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive explanation of concepts Claude already knows well (TDD, SOLID, DRY, YAGNI, KISS, error handling patterns, dependency injection). The code patterns shown are generic textbook examples that don't teach Claude anything new. Sections like 'Performance Optimization' and 'Implementation Guidelines' are pure padding with no project-specific value. | 1 / 3 |
Actionability | Code examples are present and somewhat concrete, but they are generic patterns rather than executable, copy-paste-ready instructions. The pseudocode-like workflow phases (e.g., `Write("tests/unit/auth.test.js", authTestSuite)`) are not real commands. The skill describes what to do conceptually but lacks specific, actionable tool invocations or concrete steps tied to actual tooling. | 2 / 3 |
Workflow Clarity | The Red-Green-Refactor phases provide a clear sequence, but validation checkpoints are weak — 'Verify all fail' and 'Verify all pass' are mentioned in comments but there's no explicit error recovery or feedback loop for when tests don't behave as expected. No validation steps for the refactoring phase beyond running lint. | 2 / 3 |
Progressive Disclosure | The content is a monolithic wall of text with no references to external files and no bundle files to support it. Everything is inlined — code patterns, best practices, optimization guidelines, documentation standards — much of which should be in separate reference files or omitted entirely. No navigation structure or signposting to deeper resources. | 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/claude-flow
- Commit
e6dc21f
- 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.