Rosetta debugging skill for errors, test failures, and unexpected behavior. Use proactively when encountering any issue. Ensures root cause investigation before attempting fixes.
56
64%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./instructions/r2/core/skills/debugging/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description adequately communicates its purpose as a debugging methodology skill and includes explicit 'when to use' guidance. However, it lacks specific concrete actions beyond 'root cause investigation' and could benefit from more natural trigger terms that users would actually say. The broad scope ('any issue') risks overlap with other skills.
Suggestions
Add more specific concrete actions, e.g., 'Analyzes stack traces, inspects logs, traces execution flow, and identifies root causes before applying fixes'.
Expand trigger terms with common user language variations like 'bug', 'crash', 'exception', 'broken', 'not working', 'stack trace'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (debugging) and some actions (root cause investigation, attempting fixes), but the capabilities are described at a high level rather than listing multiple concrete actions like 'analyze stack traces, inspect variable state, trace execution flow'. | 2 / 3 |
Completeness | Clearly answers both 'what' (debugging skill for errors, test failures, unexpected behavior with root cause investigation before fixes) and 'when' ('Use proactively when encountering any issue'), providing explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes relevant keywords like 'errors', 'test failures', 'unexpected behavior', and 'debugging', which users might naturally say. However, it misses common variations like 'bug', 'crash', 'exception', 'stack trace', 'broken', or 'not working'. | 2 / 3 |
Distinctiveness Conflict Risk | The term 'Rosetta' adds some distinctiveness, but 'debugging skill for errors, test failures, and unexpected behavior' is broad enough to potentially overlap with other debugging or testing skills. The phrase 'any issue' is very generic and could conflict with other problem-solving skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid debugging methodology skill with clear phase sequencing and good escalation logic. Its main weaknesses are the lack of concrete executable examples (no actual commands or code snippets) and some redundancy between the validation checklist, best practices, and the phase descriptions. The workflow is well-structured with appropriate feedback loops for a debugging process.
Suggestions
Add concrete examples: show a sample OODA analysis, a specific git command sequence for checking recent changes, or a diagnostic logging snippet to make the guidance more actionable.
Consolidate the best_practices and pitfalls sections into the relevant phases to reduce redundancy — e.g., 'one hypothesis at a time' is already stated in phase 3.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient but includes some unnecessary framing (role description, XML tags as structure, best_practices section that largely repeats earlier phases). The validation checklist partially duplicates the phase steps. However, it doesn't over-explain concepts Claude already knows. | 2 / 3 |
Actionability | Provides a clear methodology with specific steps (git diff, diagnostic logging, sequence diagrams), but lacks concrete executable examples — no actual commands, code snippets, or specific tool invocations. The guidance is specific enough to follow but not copy-paste ready. | 2 / 3 |
Workflow Clarity | The four phases are clearly sequenced with explicit ordering (phase 1-4), include validation checkpoints (validation checklist), and have a clear feedback loop (phase 3: if hypothesis fails, form new; phase 4: if 3+ fixes fail, stop and reassess architecture). The escalation path is well-defined. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but it's somewhat monolithic — the validation checklist, best practices, and pitfalls sections could be more tightly integrated or separated. References to 'load-context skill' are mentioned but not linked. No bundle files exist to offload detail into, but the content length is moderate enough that this is acceptable. | 2 / 3 |
Total | 9 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
ade2cc5
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.