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.

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, actionable workflow for a complex multi-module skill, with strong validation checkpoints, clear reference navigation, and verified bundle files. Its main weakness is conciseness: the Principles section and Step 5 overlap on the 'modify existing scenarios' guidance, adding tokens that could be consolidated.

Suggestions

Consolidate the 'prefer modifying existing scenarios' guidance: Principle 6 and Step 5's 'Prefer modifying existing scenarios' subsection cover the same rule with overlapping rationale — keep one authoritative statement and cross-reference it instead of repeating.

Trim the explanatory rationale in Principles (e.g. Principle 6's maintenance-burden paragraph) to the minimum needed to justify the rule, since the workflow steps already encode the behavior.

Add one short inline sample .feature snippet (a Given/When/Then using a real Tzatziki step pattern) so the actionability gap from delegating all examples to references is closed.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient and avoids explaining concepts Claude already knows, but the Principles section (e.g. Principle 6's maintenance-burden rationale) and the Step 5 'Prefer modifying existing scenarios' guidance repeat material already covered in Principle 6, so it could be tightened.	3 / 5
Actionability	Provides copy-paste-ready commands ('grep -o tzatziki-[a-z-]* pom.xml \| sort -u', './mvnw -pl <module> -Dtest=<RunnerClass> test') and a concrete ✅/❌ traceId example, but no inline sample .feature scenario is shown, leaving a minor gap.	4 / 5
Workflow Clarity	A clearly sequenced six-step workflow with explicit mandatory checkpoints (plan approval in Step 5, run-tests-before-responding in Step 6), named error signatures to watch for, and an explicit edit → run → fix feedback loop for both initial and subsequent modifications.	5 / 5
Progressive Disclosure	The body is an overview that points to one-level-deep, well-signaled reference files (all 11 referenced files verified present), each mapped to a specific 'read when' condition, with content appropriately split out of the main file.	5 / 5
	Total	17 / 20 Passed

Description

90%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description that clearly states what the skill does and when to use it, with rich natural trigger terms and a well-scoped niche. The only soft spot is specificity, since it foregrounds a single core action (generating .feature files) and spends the rest of its budget on triggers rather than listing multiple distinct capabilities.

Dimension	Reasoning	Score
Specificity	Names the domain and one concrete action — 'Generates Tzatziki-based Cucumber BDD tests (.feature files) from a functional specification' — but the remainder enumerates trigger contexts rather than additional distinct actions, so coverage is not comprehensive.	3 / 5
Completeness	Explicitly answers both 'what' (generates .feature files from a functional specification) and 'when' with concrete trigger phrases ('Use this skill whenever a user wants to...', 'Also use when the user mentions...').	5 / 5
Trigger Term Quality	Comprehensive natural-term coverage including synonyms and formats: 'write Cucumber tests', 'add BDD scenarios', 'create feature files', 'generate tests', 'Gherkin', 'integration tests', 'acceptance tests', 'end-to-end tests', and '.feature files'.	5 / 5
Distinctiveness Conflict Risk	A clear niche — Tzatziki-based Cucumber BDD in Java/Spring with named module surfaces (HTTP, JPA, Kafka, MongoDB, OpenSearch, logging, MCP) — gives it distinct triggers with minimal overlap risk.	5 / 5
	Total	18 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 3 missing	Warning

	Total	15 / 16 Passed

Repository: Decathlon/tzatziki
Path: skills/add-cucumber-tests/SKILL.md
Commit: ec2d274

Reviewed: 17 days ago

Table of Contents

Discovery Implementation Validation

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.