rails-bug-triage
Use when investigating a bug in a Ruby on Rails codebase and you need to turn the report into a reproducible failing spec and fix plan. Covers reproduction, scope narrowing, boundary selection, and TDD-first handoff.
80
72%
Does it follow best practices?
Impact
91%
1.49xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./rails-bug-triage/SKILL.mdQuality
Discovery
75%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 has strong completeness with an explicit 'Use when' clause and good distinctiveness for its Rails bug investigation niche. However, the capability descriptions lean toward process terminology ('scope narrowing', 'boundary selection') rather than concrete actions, and the trigger terms could be expanded to cover more natural user language variations like 'debug', 'RSpec', or 'error'.
Suggestions
Replace abstract process terms like 'scope narrowing' and 'boundary selection' with concrete actions such as 'creates RSpec reproduction tests', 'isolates failing code paths', or 'generates minimal reproduction steps'.
Add more natural trigger terms users would say, such as 'debug', 'RSpec', 'error', 'regression', 'broken test', 'Rails app', or 'stack trace'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Ruby on Rails bug investigation) and some actions (reproduction, scope narrowing, boundary selection, TDD-first handoff), but these are somewhat abstract process steps rather than concrete tool-level actions like 'create RSpec test files' or 'run test suite'. | 2 / 3 |
Completeness | Clearly answers both 'what' (turn bug report into reproducible failing spec and fix plan, covering reproduction, scope narrowing, boundary selection, TDD-first handoff) and 'when' (explicit 'Use when investigating a bug in a Ruby on Rails codebase'). | 3 / 3 |
Trigger Term Quality | Includes some natural keywords like 'bug', 'Ruby on Rails', 'failing spec', and 'TDD', but misses common variations users might say such as 'test', 'RSpec', 'debug', 'error', 'broken', 'regression', or 'Rails app'. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: Ruby on Rails bug investigation with TDD-first approach. The combination of Rails-specific context, bug reproduction, and spec-writing makes it unlikely to conflict with general debugging or testing skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
70%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured triage workflow skill with clear sequencing, explicit gates, and good integration references. Its main weakness is the lack of concrete, executable examples — no actual rspec command invocations, no skeleton spec code, and no sample triage output filled in with realistic data. The content is slightly verbose in places where tables repeat similar cautionary themes.
Suggestions
Add a concrete example of a filled-in Triage Output using a realistic Rails bug scenario (e.g., a wrong status code bug) to make the template actionable rather than abstract.
Include at least one executable rspec command and a skeleton failing spec example (e.g., a request spec) so Claude knows exactly what the 'first failing spec' deliverable looks like.
Consolidate 'Common Mistakes' and 'Red Flags' into a single section to reduce redundancy and improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but has some redundancy — the 'Common Mistakes' and 'Red Flags' sections overlap conceptually, and the 'HARD-GATE' section restates what the process already implies. The tables are well-structured but some content could be tightened. | 2 / 3 |
Actionability | The process steps are clear but remain at a descriptive/instructional level without concrete executable examples. There are no actual commands, code snippets, or specific rspec examples showing what a failing spec skeleton looks like. The 'Triage Output' template is helpful but is a reporting format, not executable guidance. | 2 / 3 |
Workflow Clarity | The 6-step process is clearly sequenced with an explicit hard gate preventing premature fixes. The workflow includes a clear validation checkpoint (reproduce before fixing, failing spec before implementation) and a defined handoff chain to downstream skills. | 3 / 3 |
Progressive Disclosure | The skill is well-organized with a quick reference table up front, detailed process in the middle, and clear one-level-deep references to chained skills (rails-tdd-slices, rspec-best-practices, etc.) in the Integration section. Content is appropriately scoped for a single SKILL.md file. | 3 / 3 |
Total | 10 / 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
- igmarin/rails-agent-skills
- Commit
ae8ea63
- 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.