用途：doc-bdd 用于在 EARS（第 3 层）已存在时，创建行为驱动开发（BDD）验收场景。它把 EARS 形式需求转为结构化 YAML 场景（Given/When/Then 阶段列表放在 ```yaml 块中，而非 Gherkin @-标签），每个场景带元素级 ears: 追溯列表，以及向前指向 SPEC 对应章节的 spec_trace。BDD 是第 4 层，下游为 ADR → SPEC → TDD → IPLAN → Code；场景是 TDD 第 7 层的验收来源。BDD 仅在 QA 预发布环境执行，绝不在 CI 中运行（CI 用 TDD 单元/集成测试）。
主要能力：文档含 5 个必需章节（文档控制、功能定义、场景结构、可追溯性、术语表）；场景覆盖五类 type：success、error、recovery、parameterized、optional，可带 outline 与 examples；支持内联 @threshold: 量化值、HH:MM:SS 时间与 IANA 时区；元素 ID 形如 BDD.NN.SS.xxxx。
使用方式：先确认上游 EARS 存在，读取模板与规范：${CLAUDE_PLUGIN_ROOT}/framework/layers/04_BDD/BDD-TEMPLATE.yaml、同层 README.md、framework/governance/ID_NAMING_STANDARDS.md 与 AUTHORING_STYLE.md；用 ls docs/03_EARS/ docs/04_BDD/ 检查上游与 ID 冲突；从模板创建文档，填写 feature: 与 scenarios:，为每个场景设置 ears: 与唯一 id:，更新 docs/04_BDD/BDD-00_index.md 后校验并提交。
适用场景：需要从 EARS 生成可执行验收场景、用 Given-When-Then 验证需求，或在 ADR/SPEC 前建立需求到 SPEC 的 spec_trace 桥。端到端生成可用 ../doc-bdd-autopilot/SKILL.md。
限制：必须先存在上游 EARS，不得虚构占位符；质量门禁要求 ADR-Ready 分数 ≥ 90/100；错误码 XDOC-006/008/009 为 error 级。当前仅提供反向一次性转换脚本 tools/gherkin_to_bdd_yaml.py，不附带 .feature 生成器。其他收费、价格与平台信息暂未提供。