058-design-bdd
FeaturedUse when a Java change needs independent Behavior-Driven Development guidance from trusted behavior facts through concrete examples and observable scenarios, with focused clarification when behavior is pending or ambiguous. This should trigger for requests such as Apply BDD; Facilitate behavior examples; Discover scenarios with Given When Then; Review these examples for shared domain language; Complete BDD discovery as a self-contained interaction. Part of Plinth Toolkit
Install
Quality Score: 92/100
Skill Content
Details
- Author
- jabrena
- Repository
- jabrena/plinth
- Created
- 1 years ago
- Last Updated
- today
- Language
- Java
- License
- Apache-2.0
Integrates with
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
054-design-tdd
Use when Java implementation work should be guided by Test-Driven Development, including maintaining a test list, choosing the next behavior, writing a failing test first, implementing only enough production code to pass, and refactoring while keeping tests green. This should trigger for requests such as Apply TDD; Use test-driven development; Drive this Java change with tests; Write the failing test first; Red-green-refactor this feature. Part of Plinth Toolkit
define-behavior
Writes behavior-driven features and scenarios in Gherkin (`.feature` files) that read as specification by example — domain-level, one behavior per scenario, observable outcomes. Use this skill whenever the user wants to author or refine Gherkin, BDD scenarios, acceptance criteria, Given/When/Then steps, feature files, or Cucumber/SpecFlow/Behave specs — even when they describe the behavior in plain prose and don't say "Gherkin". Also use to turn a ticket, user story, or acceptance criteria into scenarios, or to clean up scenarios that leak UI/API/DB mechanics. Do not use for writing the automation code behind the steps — that is a separate concern.
bdd-guide
Use when driving software from concrete agreed examples of behaviour: running three-amigos discovery and example mapping before coding, formulating Given-When-Then scenarios in feature files, and treating them as living documentation that tests the team their shared understanding. ATDD and BDD are one practice here. Triggers on BDD, ATDD, Gherkin, Given-When-Then, Cucumber, feature file, scenario / scenario outline, three amigos, example mapping, specification by example, living documentation, acceptance-test-driven, even when the user doesn't say 'BDD'.