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
Decision gist · record as of 2026-07-27
doc-bdd creates structured YAML-based BDD scenarios with Given-When-Then phases from EARS requirements, complete with traceability links. 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.
Use it when
- doc-bdd uses structured YAML (not Gherkin) to author acceptance scenarios.
- Yes.
Verify before relying
Read SKILL.md below before installing (1 file). Open directory: indexed for reading, not audited.
Install
vladm3105/aidoc-flow-framework/doc-bdd · repository language: Python
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
Frequently 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)
File tree — 1 file
platforms/claude-code-plugin/skills/doc-bdd/SKILL.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Create structured BDD scenarios in YAML from EARS requirements with Given-When-Then phases”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
verify is a quality assurance auditor that gates feature work at three checkpoints: proposal readiness, dev doc completeness, and implementation verification. It searches for placeholder content, traceability gaps, missing acceptance criteria, and specification drift, then either passes the gate or blocks with exact findings. Designed to be adversarial—assuming work is incomplete until proven otherwise.
doc-adr captures a single architectural decision using the Context-Decision-Consequences pattern, positioned as Layer 5 in the specification-driven development flow. It records the rationale, chosen approach, evaluated alternatives, and accepted trade-offs for decisions that bridge container and component design.
doc-validator enforces consistency rules across your entire SDD documentation corpus—catching broken links, orphaned artifacts, cumulative-tag gaps, duplicate IDs, and traceability gaps across all 8 layers. It runs declarative checks against your corpus structure and can optionally repair safely-fixable issues like missing reciprocal links or stale metadata. Use it before releases or after batch generation to ensure your documentation chain stays machine-verifiable and traceable.
doc-tdd generates Layer 7 TDD artifacts that translate component contracts into concrete test cases with quality thresholds. It maps BDD scenarios to unit, integration, functional, and end-to-end tests, establishes coverage targets per type, and sequences the Red-Green-Refactor workflow before implementation begins.
doc-prd generates a Product Requirements Document as Layer 2 of the SDD workflow, converting business requirements into product capabilities, user personas, and measurable success criteria. It structures features and acceptance criteria at the container level, sitting between upstream BRD and downstream EARS artifacts.
project-adopt brings an established codebase into the Specification-Driven Development workflow by detecting existing code and documentation, inferring the domain, and scaffolding the 8-layer artifact structure. It reverse-engineers baseline artifacts from your running system at draft status, seeding the SDD backbone in one setup pass. Hand off to doc-flow and per-layer audits to close gaps and promote drafts to ready.
More skills doc-adr-autopilot (MIT) · behave-skill (MIT) · serenity-bdd-skill (MIT)