implement-scenarios

Implements automated tests for existing Gherkin scenarios using outside-in BDD and traceability tags.

Updated Apr 12, 2026
One-click install
npx skills add https://github.com/azborgonovo/ai-skills --skill implement-scenarios-azborgonovo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: implement-scenarios
Source: https://github.com/azborgonovo/ai-skills/tree/main/skills/bdd/implement-scenarios
Command: npx skills add https://github.com/azborgonovo/ai-skills --skill implement-scenarios-azborgonovo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams with Gherkin .feature files often struggle to turn specifications into executable tests, ending up with misplaced end-to-end tests, no link between scenarios and code, and no way to see which behaviors are actually verified. ## Core Features & Use Cases - Scenario Classification: Assigns each scenario to the lowest test rung (unit, service via Testcontainers, or end-to-end via Playwright) that genuinely verifies it, then presents the plan for sign-off. - Outside-In Implementation: Writes one bound test per scenario, watches it fail for the right reason, then drives the UI, API, and domain code until it passes. - Traceability Matrix: Derives a scenario-to-test matrix from @SCN-NNNN tags and test references, reporting covered, unverified, uncovered, orphaned, and drifted states. - Use Case: Given a repo with SpecFlow or plain .feature files, classify all scenarios, then implement them one at a time as xUnit, pytest, Vitest, or Playwright tests with a stable ID linking each test to its scenario. ## Quick Start Ask the AI to implement and automate the scenarios in your features directory, classifying each one and binding a traceable test to it.

Frequently Asked Questions about implement-scenarios

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

FAQPage Schema
How do I automate Gherkin scenarios with tests?▼

Classify each scenario to the lowest test level that verifies it, tag it with a stable @SCN-NNNN identifier, then write one bound test that references that ID. Watch the test fail for the right reason before implementing the code that makes it pass.

How do I decide between unit, service, and end-to-end tests for a scenario?▼

Pick the lowest rung that genuinely verifies the behavior: unit for domain logic, service with Testcontainers for behavior across real adapters like persistence or HTTP, and end-to-end with Playwright only for genuine user journeys through the UI.

Does this work with SpecFlow, Reqnroll, or Cucumber projects?▼

Yes. Where a Gherkin runner already exists, write step bindings so the .feature file stays executable. In projects without a runner, write plain tests that carry the scenario ID, without imposing a Cucumber framework.

How do I track which Gherkin scenarios have test coverage?▼

Derive a trace matrix by reconciling @SCN tags in .feature files against ID references in tests using ripgrep. Each scenario is reported as covered, unverified, uncovered, orphaned-ref, or drifted.

What happens when Docker or a browser is unavailable for tests?▼

When Testcontainers or Playwright infrastructure cannot start, the test is still generated but the scenario is marked unverified in the report. A green result is never claimed without witnessing the test pass.