add-cucumber-tests
Generates Tzatziki-based Cucumber BDD tests (.feature files) from a functional specification. Use this skill whenever a user wants to write Cucumber tests, add BDD scenarios, create feature files, generate tests, or test application behaviors with Gherkin — especially in Java/Spring projects using Tzatziki step definitions for HTTP, JPA, Kafka, MongoDB, OpenSearch, logging, or MCP. Also use when the user mentions writing integration tests, acceptance tests, or end-to-end tests in a project that already has Tzatziki/Cucumber dependencies, including TestNG-based setups.
94
92%
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 an excellent skill description that clearly defines what it does (generates Tzatziki-based Cucumber BDD .feature files from specs), when to use it (comprehensive trigger conditions), and occupies a distinct niche. The description is thorough with natural trigger terms covering multiple user phrasings, and the technology-specific details help differentiate it from generic testing skills. It uses proper third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists concrete actions: generates .feature files from functional specifications, and specifies the technology stack (Tzatziki, Cucumber, Gherkin) along with specific integrations (HTTP, JPA, Kafka, MongoDB, OpenSearch, logging, MCP). It clearly names the domain and multiple specific capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (generates Tzatziki-based Cucumber BDD tests from functional specifications) and 'when' (explicit 'Use this skill whenever...' clause with detailed trigger conditions including specific scenarios like Java/Spring projects, Tzatziki dependencies, and TestNG-based setups). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'Cucumber tests', 'BDD scenarios', 'feature files', 'generate tests', 'Gherkin', 'integration tests', 'acceptance tests', 'end-to-end tests', 'Tzatziki', '.feature files'. These cover many natural variations a user might use when requesting this type of work. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — the combination of Tzatziki framework, Cucumber/BDD, .feature files, and the specific technology stack (Java/Spring, JPA, Kafka, MongoDB, OpenSearch) creates a very clear niche that is unlikely to conflict with generic testing or code generation skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality, well-structured skill that provides a clear, actionable workflow for generating Tzatziki-based Cucumber BDD tests. Its greatest strengths are the explicit validation checkpoints, the mandatory test-run feedback loops, and the well-organized progressive disclosure to reference files. The main weakness is verbosity — several key points (especially around not inventing steps and running tests after every edit) are repeated across multiple sections, which could be consolidated to save tokens.
Suggestions
Consolidate repeated guidance about 'never invent steps' and 'always run tests after edits' — these appear in Principles, Workflow steps, and Success Criteria. State the rule once authoritatively and reference it elsewhere rather than restating it in full.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is thorough and mostly well-targeted, but it's quite verbose (~300+ lines). Several principles and workflow steps repeat the same points (e.g., 'never invent steps' is stated in Principle 1, Step 6, and Success Criteria). The detailed edge-case identification guidance and the 'prefer modifying existing scenarios' section, while useful, could be tightened. However, it avoids explaining basic concepts Claude already knows (Cucumber, Gherkin, etc.). | 2 / 3 |
Actionability | The skill provides highly concrete, executable guidance: specific bash commands for dependency detection (`grep -o 'tzatziki-[a-z-]*' pom.xml`), exact Maven/Gradle test execution commands, specific error strings to look for in output (`step(s) are undefined`, `UndefinedStepException`, `ParseError`), and clear references to step definition files. The workflow is prescriptive with copy-paste-ready commands. | 3 / 3 |
Workflow Clarity | The 6-step workflow is clearly sequenced with explicit mandatory checkpoints (Steps 5 and 6 marked with ⛔), validation loops (edit → run → fix), and specific success/failure criteria. The feedback loop for undefined steps is thoroughly defined, and the post-implementation modification sub-workflow ensures validation isn't skipped even for small changes. Destructive/batch operation concerns are well-addressed. | 3 / 3 |
Progressive Disclosure | The skill has excellent progressive disclosure structure: the main SKILL.md provides the workflow overview and principles, while detailed step definitions, bootstrap templates, and CLI execution details are cleanly delegated to clearly-named reference files (9 per-module step references + 2 other references). References are one level deep, well-signaled with descriptions, and organized by dependency module. Navigation is straightforward. | 3 / 3 |
Total | 11 / 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
- Decathlon/tzatziki
- Commit
d4a7ab6
- 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.