tdd-cycle
Guides Test-Driven Development workflow with Red-Green-Refactor cycle. Use when the user wants to implement a feature using TDD, write tests first, follow test-driven practices, or mentions red-green-refactor.
Install with Tessl CLI
npx tessl i github:fernandezbaptiste/rails_ai_agents --skill tdd-cycle86
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 solid skill description with excellent trigger terms and completeness. The explicit 'Use when...' clause with multiple natural trigger phrases makes it easy for Claude to select appropriately. The main weakness is that the capabilities could be more specific about what concrete actions the skill guides (e.g., writing failing tests, implementing minimal code, refactoring).
Suggestions
Expand the capabilities portion to list specific actions: 'Guides writing failing tests first, implementing minimal code to pass, and refactoring for quality'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (TDD) and mentions 'Red-Green-Refactor cycle' as a specific methodology, but doesn't list concrete actions like 'write failing tests', 'implement minimal code', or 'refactor for clarity'. | 2 / 3 |
Completeness | Clearly answers both what ('Guides Test-Driven Development workflow with Red-Green-Refactor cycle') and when ('Use when the user wants to implement a feature using TDD, write tests first, follow test-driven practices, or mentions red-green-refactor'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'TDD', 'write tests first', 'test-driven', 'red-green-refactor'. These cover common variations of how users would request this workflow. | 3 / 3 |
Distinctiveness Conflict Risk | TDD is a distinct methodology with specific terminology (red-green-refactor) that wouldn't conflict with general testing or coding skills. The triggers are specific to this practice. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%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 TDD skill with excellent actionability and workflow clarity. The step-by-step process with explicit validation checkpoints is particularly strong. However, it could be more concise by trimming explanations of concepts Claude already knows and better utilizing progressive disclosure to move detailed patterns into separate reference files.
Suggestions
Move the 'Common Patterns' section to a separate PATTERNS.md file and link to it, keeping only 1-2 examples inline
Remove explanatory text like 'Before writing any code, understand' and the requirement analysis questions - Claude knows how to analyze requirements
Condense the 'Good Spec Characteristics' bullet points into a single-line reminder or remove entirely as these are standard RSpec practices
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary explanation (e.g., 'Ask clarifying questions if requirements are ambiguous' and basic TDD concepts Claude already knows). The tables and templates are useful but some sections could be tightened. | 2 / 3 |
Actionability | Provides fully executable Ruby/RSpec code examples that are copy-paste ready. Includes specific bash commands for running tests, concrete spec structures, and multiple practical patterns for validations, associations, scopes, and services. | 3 / 3 |
Workflow Clarity | Excellent multi-step workflow with explicit validation checkpoints at Steps 4, 6, and 8. Includes a trackable checklist, clear feedback loops ('If specs fail, undo and try different approach'), and explicit verification requirements at each stage. | 3 / 3 |
Progressive Disclosure | References external templates (unit_spec.erb, request_spec.erb) appropriately, but the main content is somewhat monolithic. The common patterns section could be split into a separate reference file, and the anti-patterns could be more concisely linked rather than inline. | 2 / 3 |
Total | 10 / 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 |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
- 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.