doc-bdd
doc-bdd translates EARS requirements into Layer 4 acceptance scenarios using structured YAML (not Gherkin), each with Given-When-Then phases, element-level trace links to upstream EARS, and forward mapping to SPEC sections. Use this after EARS is complete and before ADR/SPEC authoring; for batch generation across multiple documents, the autopilot skill handles orchestration.
doc-bdd creates structured YAML-based BDD scenarios with Given-When-Then phases from EARS requirements, complete with traceability links.
AI-generated summary based on this skill's SKILL.md
Install
vladm3105/aidoc-flow-framework/doc-bdd · repository language: Python
git clone https://github.com/vladm3105/aidoc-flow-framework
cp -r aidoc-flow-framework/platforms/claude-code-plugin/skills/doc-bdd ~/.claude/skills/doc-bddnpx skillfed install vladm3105/aidoc-flow-framework/doc-bddFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I create BDD scenarios from EARS requirements?
doc-bdd translates EARS requirements into Layer 4 acceptance scenarios using structured YAML format. Each scenario includes Given-When-Then phases that map directly to your EARS acceptance criteria. Start with a completed EARS document, then use doc-bdd to generate executable test scenarios with element-level trace links back to the source EARS requirement and forward to your SPEC sections.
What format does doc-bdd use for acceptance test scenarios?
doc-bdd uses structured YAML (not Gherkin) to author acceptance scenarios. Each scenario contains Given-When-Then phases organized as YAML blocks, making them both human-readable and machine-parseable. This format bridges EARS requirements and executable tests while maintaining full traceability through upstream/downstream trace links at the element level.
Can doc-bdd convert EARS to behavior driven development?
Yes. doc-bdd converts EARS acceptance criteria into Layer 4 BDD scenarios with Given-When-Then structure. It maps each EARS element to one or more scenario categories (success, error, recovery, parameterized, optional) with assigned priorities, then generates QA-staging acceptance test suites ready for execution while preserving requirement traceability.
What scenario categories does doc-bdd define?
doc-bdd organizes acceptance scenarios into five categories: success (happy path), error (failure handling), recovery (resilience), parameterized (data-driven variants), and optional (conditional flows). Each category receives a priority assignment to guide QA staging and test execution order.
When should I use doc-bdd in my documentation workflow?
Use doc-bdd after your EARS requirements are complete and before you begin ADR/SPEC authoring. It serves as the bridge between requirements and specification by generating Layer 4 acceptance scenarios with full trace links. For batch generation across multiple documents, the autopilot skill handles orchestration.
Does doc-bdd provide traceability between requirements and tests?
Yes. doc-bdd generates acceptance scenarios with element-level traceability, linking each scenario upstream to its source EARS requirement and downstream to relevant SPEC sections. This dual-direction trace mapping ensures your acceptance tests remain synchronized with both upstream requirements and downstream specifications throughout the documentation lifecycle.
SKILL.md
rendered from the published skill — quoted content, verbatim
doc-bdd
Purpose
Create Behavior-Driven Development (BDD) scenarios — Layer 4 of the SDD
flow. A BDD suite translates EARS formal requirements into structured YAML
scenarios (Given/When/Then phase lists carried in a ```yaml block, NOT
Gherkin @-tags), each carrying an element-level ears: trace list and a
spec_trace link forward to the SPEC sections it exercises. (If a runner ever
needs .feature files, the YAML is the source
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
platforms/claude-code-plugin/skills/doc-bdd/SKILL.md