aibdd-feature-file-writing-principle

Standardizes AIBDD .feature files with data-complete Gherkin scenarios and full-result verification.

77|15|Updated May 12, 2026
One-click install
npx skills add https://github.com/Waterball-Software-Academy/aixbdd --skill aibdd-feature-file-writing-principle
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: aibdd-feature-file-writing-principle
Source: https://github.com/Waterball-Software-Academy/aixbdd/tree/main/.agents/skills/aibdd-feature-file-writing-principle
Command: npx skills add https://github.com/Waterball-Software-Academy/aixbdd --skill aibdd-feature-file-writing-principle

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents AIBDD feature files from degrading into “test-like steps without a rebuildable specification” by enforcing Specification by Example, data-complete Given sections, full result verification, and robust negative-path and idempotency coverage.

Core Features & Use Cases

  • Specification by Example (SSOT): Ensures every feature example provides concrete inputs, actions, and observable outputs.
  • Data-complete Given: Requires fixture manifests, templates, and seed/expected artifacts to be explicitly present rather than implicitly “known” from repo context.
  • Full-result verification: Prioritizes exact comparisons of full projections (e.g., complete JSON) and full file contents over single-field or partial assertions.
  • Negative-path rigor: Forces unknown directive/error scenarios to assert error classification plus exact preserved original text where applicable.
  • Idempotency coverage: Requires separate examples that demonstrate reruns do not change outputs.
  • Fixture-driven, harness CLI orientation: Encourages expressing specs using generalized, filesystem-oriented, CLI-driven harness workflows.

Quick Start

Ask an AI agent to rewrite your AIBDD .feature files following the aibdd-feature-file-writing-principle so each Scenario is data-complete, negative paths and idempotency are explicitly tested, and assertions verify complete outputs and preserved original text.

Frequently Asked Questions about aibdd-feature-file-writing-principle

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write executable Gherkin feature files for acceptance testing?▼

Executable Gherkin feature files standardize specifications using Specification by Example, ensuring every Scenario provides concrete inputs, actions, and observable outputs rather than implicit test-like steps.

What is Specification by Example in feature files and why does it matter?▼

Specification by Example treats feature files as a single source of truth by requiring data-complete Given sections with explicit fixture manifests and seed artifacts, preventing specifications from degrading into partial, context-dependent steps.

How do I structure negative paths and idempotency in Gherkin scenario outlines?▼

Structure negative paths by asserting error classification and exact preserved original text, and write separate idempotency scenario outlines that explicitly demonstrate reruns produce no output changes.

Can I use fixture harness CLI workflows for filesystem-oriented acceptance testing?▼

Fixture harness CLI workflows support filesystem-oriented acceptance testing by expressing generalized specs around manifest loading and fixture bundle application through command-line driven actions.

Why do my feature file assertions fail to catch regressions in full JSON outputs?▼

Single-field or partial assertions miss regressions in untested projection fields. Full-result verification prioritizes exact comparisons of complete JSON projections and full file contents to ensure complete output validation.