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.

LANGUAGE CONVENTION FRAME (read FIRST, overrides all examples below)

Code examples in this skill use Python syntax for illustration only. They are NOT prescriptive about target language. nWave is language-agnostic per the "genericity and agnosticism" mandate (2026-05-24).

Before authoring ATs, detect the target project's language from these manifest files (in order):

• package.json → TypeScript / JavaScript (jest, vitest, cucumber-js, playwright)
• Cargo.toml → Rust (cargo test, proptest, cucumber-rust)
• go.mod → Go (testing, ginkgo, godog)
• pyproject.toml / setup.py / Pipfile → Python (pytest, pytest-bdd, hypothesis)
• pom.xml / build.gradle → Java / Kotlin (JUnit5, Cucumber-JVM, jqwik)
• *.csproj / *.fsproj → C# / F# (xUnit, SpecFlow, FsCheck)
• Gemfile → Ruby (RSpec, Cucumber-Ruby)
• Package.swift → Swift (XCTest, swift-testing)

When the target language is NOT Python:

1. Adapt EVERY code example to the target language's conventions (naming, imports, type system, test-framework idioms, file extensions).
2. Replace Python-specific imports (from pytest_bdd import ..., from hypothesis import ..., import dataclasses) with target-language equivalents (import { Given, When, Then } from '@cucumber/cucumber', import * as fc from 'fast-check', etc.).
3. Replace Python type hints (def f(x: int) -> str) with target-language type syntax.
4. Replace Python directory conventions (tests/, __init__.py) with target conventions (test/, __tests__/, no init files for TS/JS).
5. Replace Python class/function syntax (class Customer:, def given_port():) with target equivalents.