rspec-service-testing
Use when writing RSpec tests for service objects, API clients, orchestrators, or business logic in spec/services/. Covers instance_double, FactoryBot hash factories, shared_examples, subject/let blocks, context/describe structure, aggregate_failures, change matchers, travel_to, and error scenario testing.
86
82%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%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 is a strong skill description that clearly defines its scope (RSpec service specs), provides explicit trigger guidance via a 'Use when' clause, and enumerates specific techniques covered. The description is concise yet comprehensive, listing both the contexts for use and the concrete RSpec patterns it addresses, making it easy for Claude to select appropriately from a large skill set.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and concepts: instance_double, FactoryBot hash factories, shared_examples, subject/let blocks, context/describe structure, aggregate_failures, change matchers, travel_to, and error scenario testing. These are highly specific RSpec testing techniques. | 3 / 3 |
Completeness | Explicitly answers both 'what' (covers instance_double, FactoryBot hash factories, shared_examples, etc.) and 'when' (starts with 'Use when writing RSpec tests for service objects, API clients, orchestrators, or business logic in spec/services/'). The 'Use when' clause is explicit and well-defined. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a developer would use: 'RSpec tests', 'service objects', 'API clients', 'orchestrators', 'business logic', 'spec/services/', 'FactoryBot', 'shared_examples', 'instance_double', 'change matchers', 'travel_to'. These are all terms developers naturally use when discussing Ruby testing. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: RSpec tests specifically for service objects in spec/services/. The combination of the directory path, the specific object types (service objects, API clients, orchestrators), and the enumerated RSpec techniques makes this unlikely to conflict with other testing skills (e.g., model specs, controller specs, or integration tests). | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%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, actionable skill with excellent concrete examples and a useful template for service specs. Its main weaknesses are moderate redundancy across sections (quick reference, conventions, checklist all overlap) and the lack of an explicit test-run-verify workflow. The content would benefit from tightening repeated guidance and adding a brief feedback loop for running and validating tests.
Suggestions
Add an explicit workflow section: write spec → run rspec → check output → fix failures → re-run, to provide a validation feedback loop
Consolidate the Quick Reference table, Conventions section, and Checklist to eliminate redundancy — pick one format for each piece of guidance rather than restating it three ways
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some redundancy — the Conventions section largely restates what's already shown in the template and quick reference table. The Common Mistakes and Red Flags sections overlap somewhat. The checklist also repeats guidance from earlier sections. | 2 / 3 |
Actionability | Provides fully executable Ruby code examples including a complete spec template, FactoryBot hash factory definition, instance_double usage, and concrete patterns. The template is copy-paste ready and the examples are specific and complete. | 3 / 3 |
Workflow Clarity | The checklist provides a clear sequence for new test files, and the template shows a well-structured spec. However, there's no explicit validation/verification workflow — no steps for running the tests, checking coverage, or iterating on failures. For a testing skill, a 'write → run → verify → fix' feedback loop would strengthen this. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and tables, but it's somewhat monolithic — the FactoryBot hash factory section, error scenarios guide, and common mistakes could be split into referenced files. The Integration table at the end references other skills nicely, but the main file tries to cover everything inline. | 2 / 3 |
Total | 9 / 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.