implement-scenarioslisted

# Implement Scenarios BDD runs on three practices: **discovery** (what the system could do), **formulation** (capturing it as Gherkin), and **automation** (wiring scenarios to code so you know what the system actually does). `define-behavior` lives in formulation; this skill is automation. It takes `.feature` files that already exist and makes them executable, working outside-in: for each scenario, write the test that proves the behavior *before* the code that delivers it, then build inward until it passes. As the TDD discipline puts it — if you didn't watch the test fail, you don't know it tests the right thing. Your distinctive job is the three things generic TDD doesn't cover: **classify** each scenario to the testing strategy that verifies it most cheaply, **bind** a test to it through a stable identifier, and **trace** the link so anyone can see which scenarios are covered. The inner red-green loop that grows the production code is ordinary TDD — drive it well, but the skill's taught core is classify, bind, and trace, not re-teaching unit testing. Work in two phases, and keep them separate: classify the whole suite and get sign-off *first*, then implement one scenario at a time. Planning benefits from the global view; implementation must not. Writing every test up front and then all the code (horizontal slicing) produces tests that verify imagined behavior rather than real behavior — build vertical slices instead, one scenario fully red-to-green before the next. ## O