BDD Full-Spectrum Quality

"If you can't express it as a Given/When/Then, you don't understand it well enough to build it."

TL;DR

Generates Behavior-Driven Development scenarios that go beyond functional happy paths. Every feature gets Gherkin scenarios across all relevant quality angles: functional, accessibility, security, performance, SEO, offline, UI, backend, data, DevSecOps, and CI/CD. Step definitions are runner-agnostic — Playwright for browser tests, Vitest for code invariants, Firebase Emulator for security rules. Each scenario traces to a requirement (FR-XXX), success criterion (SC-XXX), and constitutional principle. [EXPLICIT]

Procedure

Step 1: Discover

• Read the feature specification (FR-XXX, SC-XXX)
• Identify which quality angles apply to this feature
• Review constitutional principles that govern the feature
• Check existing .feature files for coverage gaps

Step 2: Analyze

• For each applicable angle, derive at least one Given/When/Then scenario
• Coverage angles (select all that apply):
  • @functional — Does the feature do what it should?
  • @a11y — Is it keyboard-navigable, screen-reader friendly, ARIA-correct?
  • @security — Are inputs sanitized? Rules enforced? No secrets exposed?
  • @perf — Does it meet Lighthouse budgets? Load within 2s on 3G?
  • @seo — Meta tags present? Structured data correct? Crawlable?
  • @offline — Degrades gracefully? Cached content displayed?
  • @ui — Design tokens used? No hardcoded colors/fonts?
  • @backend — Security rules pass? Data model validates?
  • @data — Schema enforced? Both languages present? Audit logged?
  • @devsecops — No secrets in client code? Rules tested pre-deploy?
  • @cicd — Gates block broken code? Tests run before merge?
• Map each scenario to its runner:
  • Browser-dependent → Playwright
  • Code structure invariants → Vitest/grep
  • Security rules → Firebase Emulator
  • Performance → Lighthouse CI

Step 3: Execute

• Write .feature files with Gherkin syntax:

  @functional @TS-022
  Feature: Task creation
    Scenario: User creates a new task
      Given I am logged in as a team member
      When I enter "Buy groceries" in the task input
      And I click the "Add" button
      Then a task "Buy groceries" appears in the task list
      And the task has status "todo"
  
  @security @TS-024
  Feature: Input sanitization
    Scenario: HTML tags are stripped from task input
      Given I am logged in as a team member
      When I enter "<script>alert('xss')</script>Buy groceries" in the task input
      And I click the "Add" button
      Then the stored task title is "Buy groceries"
      And no script tags exist in the DOM

• Generate step definition stubs for the chosen runner
• Add traceability tags: @TS-xxx (requirement), @SC-xxx (success criterion), @P-xxx (principle)
• Hash-lock feature files after approval (changes require re-running testify phase)

Step 4: Validate

• Every quality angle relevant to the feature has at least 1 scenario
• All scenarios have step definition stubs
• Runner assignment matches the test nature (not all forced through browser)
• Traceability tags link to existing requirements
• No ambiguous terms in scenarios (trigger Socratic debate if found)
• Feature file hash recorded for drift detection

Quality Criteria

• All applicable quality angles have at least 1 scenario
• Scenarios use Given/When/Then syntax correctly
• Tags include angle (@functional), requirement (@TS-xxx), and principle (@P-xxx)
• Step definitions are runner-agnostic (runner chosen per nature of test)
• No ambiguous or untestable assertions
• Feature files hash-locked after approval
• Evidence tags applied to all claims

Anti-Patterns

Related Skills

• test-strategy — Overall test pyramid and automation architecture
• e2e-testing — Playwright-specific implementation of browser scenarios
• unit-testing — Vitest/Jest implementation of code invariant scenarios
• security-testing — Security-specific test patterns
• socratic-debate — Resolve ambiguous scenarios before implementation

Usage

Example invocations:

• "/bdd-full-spectrum" — Run the full bdd full spectrum workflow
• "bdd full spectrum on this project" — Apply to current context

Assumptions & Limits

• Assumes access to project artifacts (code, docs, configs) [EXPLICIT]
• Requires English-language output unless otherwise specified [EXPLICIT]
• Does not replace domain expert judgment for final decisions [EXPLICIT]

Edge Cases

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output.