用途：该技能提供一套将行为驱动开发（BDD）原则应用于编码任务的指南，面向需要实现功能、修复缺陷或重构代码的场景。核心主张是把 BDD 当作共享理解与高质量实现的方法论，而非单纯工具。
主要能力：引导先理解行为再编码；定义具体示例（Gherkin 场景）；用测试驱动实现。流程从需求流向代码，分为发现（通过示例澄清需求）、形式化（写成 Given/When/Then 场景）、自动化（用 TDD 落地）三个阶段。场景作为可执行规格，要求声明式、聚焦业务、避免技术术语与 UI 细节，每个场景只对应一种行为。
使用方式：在规划阶段，将评审过的 Given/When/Then 场景保留在 docs/plans/.../bdd-specs.md，供设计评审、任务分解与迭代契约共用同一来源；进入实现后，把要自动化的场景翻译为 .feature 文件或框架原生的可执行测试格式，而不是代码注释。实现引擎为 Red-Green-Refactor：先写失败测试、再写最小实现让其通过、最后在测试通过的前提下清理代码。
限制与铁律：资料强调“没有先失败的测试就不写生产代码”。Red 步骤必须先运行测试、确认其因正确原因失败，才能编写实现。若生产代码已存在，应删除并基于失败测试重新推导，不得保留作参考、不得边看代码边写测试。文中列出的常见合理化借口（事后补测试、已手工验证、太简单不需要测试、务实跳过、沉没成本等）均被否定。唯一合法例外限于一次性原型、生成代码和配置文件，且应与用户确认而非默认。
参考文件：./references/bdd-best-practices.md 涵盖方法论、发现、形式化与自动化；./references/gherkin-guide.md 涵盖语法、存储结构与示例；./references/testing-anti-patterns.md 涵盖 Mock 陷阱等。