testing-patterns
Write automated tests using RSpec, Capybara, and FactoryBot for Rails applications. Use when implementing features, fixing bugs, or when the user mentions testing, specs, RSpec, Capybara, or test data. Avoid using rails console or server for testing.
82
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/testing-patterns/SKILL.mdQuality
Discovery
89%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 well-crafted skill description with strong trigger terms, explicit 'Use when' guidance, and clear distinctiveness through named frameworks. Its main weakness is that the 'what' portion could be more specific about the types of tests or concrete actions (e.g., model specs, request specs, system tests, factory definitions). The negative boundary about avoiding rails console is a nice touch for disambiguation.
Suggestions
Expand the capabilities list with more specific actions, e.g., 'Write model specs, request specs, system tests, and define test factories' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (automated tests for Rails) and key tools (RSpec, Capybara, FactoryBot), but doesn't list multiple specific concrete actions beyond 'write automated tests'. Could specify unit tests, integration tests, system tests, model specs, request specs, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (write automated tests using RSpec, Capybara, and FactoryBot for Rails applications) and 'when' (explicit 'Use when' clause covering implementing features, fixing bugs, or mentions of testing/specs/RSpec/Capybara/test data). Also includes a helpful negative boundary ('Avoid using rails console or server'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'testing', 'specs', 'RSpec', 'Capybara', 'test data', 'implementing features', 'fixing bugs'. These cover common variations of how users would request testing help in Rails projects. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: Rails testing with named frameworks (RSpec, Capybara, FactoryBot). Unlikely to conflict with other skills due to the specific technology stack and the explicit negative constraint about rails console/server. | 3 / 3 |
Total | 11 / 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 testing skill with excellent concrete examples, particularly the let vs let! pitfall demonstration and the Turbo confirm helper. Its main weaknesses are verbosity in explaining concepts Claude already knows (basic RSpec conventions, what the tools are), a lack of workflow sequencing with validation checkpoints, and a monolithic structure that could benefit from splitting detailed patterns into referenced files.
Suggestions
Remove the 'Future Topics' section entirely — it provides no actionable value and wastes tokens.
Trim general guidelines that Claude already knows (e.g., 'Keep tests focused and readable', 'Use descriptive context and describe blocks', the Tech Stack definitions) to reclaim token budget.
Add a brief workflow section showing the sequence: write factory → write spec → run `bundle exec rspec path/to/spec` → fix failures → re-run, with explicit validation checkpoints.
Consider splitting the Turbo confirm helper setup and the detailed let/let! examples into separate referenced files to improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary explanation that Claude would already know (e.g., 'RSpec - Testing framework', 'Capybara - System/integration testing', general guidelines like 'Write tests first or alongside implementation', 'Keep tests focused and readable'). The let vs let! section is valuable but slightly verbose with the 'Key Insight' summary repeating what was already demonstrated. The 'Future Topics' section adds no value. | 2 / 3 |
Actionability | The skill provides fully executable, copy-paste ready code examples throughout — validation testing patterns, system test examples, factory usage, Turbo confirm helper setup, and data-testid patterns. Each section includes concrete, working Ruby/RSpec code with clear context. | 3 / 3 |
Workflow Clarity | The skill covers individual testing patterns well but lacks a clear sequenced workflow for writing tests end-to-end. There are no explicit validation checkpoints (e.g., 'run the test suite after writing each spec', 'verify factory validity before using in system tests'). The test command is mentioned but not integrated into a workflow with feedback loops. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sections, but it's a long monolithic file (~200 lines) with no references to external files. The Turbo confirm helper setup and detailed let/let! examples could be split into separate reference files. The 'Future Topics' section hints at content that doesn't exist yet, which is unhelpful. | 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
- RoleModel/rolemodel-skills
- Commit
097ad6b
- 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.