CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/bdd-overview

Teaches behaviour-driven development end to end for a newcomer: what BDD is and how discovery, formulation and automation fit together; a decision table that picks the runner from the project's language and build files (Cucumber-JVM, Cucumber-JS, Cucumber-Ruby, Behave for Python, Reqnroll for .NET, and why SpecFlow is end-of-life); install and first-run commands for each; the declarative-versus-imperative Gherkin discipline with a worked bad-versus-good pair; Background, Scenario Outline and domain-organised step libraries; the traps that make BDD collapse into an expensive UI-automation wrapper; and an honest account of when BDD is not worth adopting. Use when a team is adopting BDD, choosing a Gherkin runner, or a *.feature file needs writing and nobody has settled the conventions.

70

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

72%

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

The body is highly actionable with executable commands, a concrete runner-selection table, and worked Gherkin examples, plus clean one-level-deep progressive disclosure. Its weakness is conciseness — conceptual explanation and citation padding — and the absence of explicit error-recovery feedback loops in the first-run workflow.

Suggestions

Tighten conceptual sections (What BDD is, Three Amigos, Background/Scenario Outline mechanics) to the minimum a newcomer needs, and trim the block-quote citations from cucumber.io to the essential claims.

Add a brief error-recovery loop to the first-run path (e.g. 'if steps are ambiguous rather than undefined, check the runner version and step-definition folder layout') to lift workflow clarity.

Move the per-runner install/first-run command table or the SpecFlow migration detail into a reference file to reduce spine length while keeping the runner-selection decision table prominent.

DimensionReasoningScore

Conciseness

Mostly efficient practitioner guidance (runner table, SpecFlow trap, anti-patterns, traps list) but padded with conceptual explanation Claude largely already knows (what BDD is, Three Amigos, Background/Scenario Outline mechanics) and many block-quote citations from cucumber.io that could be tightened.

2 / 3

Actionability

Fully executable, copy-paste-ready commands for each runner (e.g. 'dotnet new install Reqnroll.Templates.DotNet', 'npm install --save-dev @cucumber/cucumber'), a decision table mapping repo files to a runner, and concrete bad-versus-good Gherkin examples — not vague direction.

3 / 3

Workflow Clarity

A clear conceptual sequence (understand → pick runner → first run → discipline → traps → when to skip) with an explicit first-run success checkpoint ('the runner reports undefined steps... the correct first result, not a failure'), but no explicit error-recovery feedback loops or checklists that anchor 3 requires.

2 / 3

Progressive Disclosure

The spine stays focused (inline .NET/Reqnroll path) and clearly signals a one-level-deep reference to references/runner-setup.md for the other four runners; the referenced bundle file exists and is genuinely one level deep with no nested indirection.

3 / 3

Total

10

/

12

Passed

Description

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.

The description is highly specific, complete, and distinctive with a strong explicit 'Use when...' trigger and third-person voice. Its only weakness is verbosity: it reads as a table of contents, and the conciseness guideline discourages rewarding padded length even when the content is concrete.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions — 'a decision table that picks the runner from the project's language and build files', 'install and first-run commands for each', 'the declarative-versus-imperative Gherkin discipline with a worked bad-versus-good pair', 'Background, Scenario Outline and domain-organised step libraries' — rather than vague language, though the sheer length adds padding.

3 / 3

Completeness

Clearly answers both what (end-to-end BDD teaching with enumerated components) and when (explicit 'Use when...' clause with concrete triggers), exceeding the bar that caps completeness at 2 when trigger guidance is missing.

3 / 3

Trigger Term Quality

The 'Use when a team is adopting BDD, choosing a Gherkin runner, or a *.feature file needs writing and nobody has settled the conventions' clause covers natural terms a user would actually say ('adopting BDD', 'Gherkin runner', '*.feature file').

3 / 3

Distinctiveness Conflict Risk

A clear niche — BDD/Gherkin runner selection and feature-file conventions — with triggers ('adopting BDD', 'choosing a Gherkin runner', '*.feature file needs writing') unlikely to fire for unrelated skills.

3 / 3

Total

12

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents