nw-distilllisted

# DISTILL Methodology: Acceptance Test Creation This skill provides the acceptance designer's methodology for creating acceptance tests. The orchestrator controls the overall flow (agent dispatch, review gate, handoff) -- this skill focuses on HOW to create good acceptance tests. ## Acceptance Criteria: Port-to-Port Principle Every AC MUST name the driving port (entry point) through which the behavior is exercised. This enables port-to-port acceptance tests that make TBU (Tested But Unwired) defects structurally impossible. Each AC includes: 1. **Observable outcome**: what the user/system sees 2. **Driving port**: the entry point that triggers the behavior (service, handler, endpoint, CLI command) Without the driving port, a crafter can write correct code that is never wired into the system. **Features**: "When user {action} via {driving_port}, {observable_outcome}" **Bug fixes**: "When {trigger}, {modified_code_path} produces {correct_outcome} instead of {current_broken_behavior}" ## Prior Wave Reading Before writing any scenario, read SSOT and feature delta artifacts. **READING ENFORCEMENT**: You MUST read every file listed in steps 1-5 below using the Read tool before proceeding. After reading, output a confirmation checklist (`+ {file}` for each read, `- {file} (not found)` for missing). Do NOT skip files that exist. 1. **Read Journeys** — Read `docs/product/journeys/{name}.yaml`. Extract embedded Gherkin as starting scenarios, identify integration checkpoints a