acceptance-testing

Authors production-composed acceptance scenarios for user-visible flows before implementation.

3|Updated Aug 3, 2026
One-click install
npx skills add https://github.com/gen4recomp/gen4recomp --skill acceptance-testing-gen4recomp
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: acceptance-testing
Source: https://github.com/gen4recomp/gen4recomp/tree/main/.agents/skills/acceptance-testing
Command: npx skills add https://github.com/gen4recomp/gen4recomp --skill acceptance-testing-gen4recomp

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often confuse acceptance tests with lower-layer checks like ROM conformance or graphics smoke tests, or write acceptance scenarios after implementation that merely rubber-stamp existing behavior. This Skill enforces a contract-first discipline: acceptance scenarios are authored before implementation, boot the real production composition, and stay red for the intended missing behavior until the feature lands. ## Core Features & Use Cases - Contract-first scenario authoring: Add or update acceptance scenarios before production code, verify they fail for the intended missing behavior, then freeze the contract so implementation cannot quietly weaken it. - Production composition enforcement: Boot the real non-rendering runtime through the shared acceptance harness instead of hand-assembling sessions, faking only true host boundaries like audio output, wall clock, and save roots. - Layer boundary discipline: Distinguish acceptance from ROM conformance and graphics smoke tests, stop before GPU rendering, and record precise exemptions for non-behavioral deliverables. - Use Case: When a deliverable changes dialogue flow or map transitions in the LÖVE runtime, author a scenario that drives semantic input through the production runtime, waits on semantic state, and asserts user-visible outcomes across each ready game version. ## Quick Start Ask the agent to author an acceptance scenario for the new dialogue flow deliverable using the production-composed acceptance harness before any implementation begins.

Frequently Asked Questions about acceptance-testing

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

FAQPage Schema
How do I write acceptance tests before implementation?

Author the scenario against the production composition path first, run it to confirm it fails for the intended missing behavior, then freeze the contract. Implementation proceeds only after the red result names the missing behavior rather than a syntax or require error.

What is the difference between acceptance tests and integration tests?

Acceptance tests prove a user-visible flow through the full production composition, stopping before GPU rendering. Lower layers like ROM conformance validate parsers and digesters without any user-visible flow, and graphics smoke tests only verify shaders and canvases compile.

When should I skip writing an acceptance test?

Skip acceptance only for non-behavioral deliverables that cross no user-visible boundary, such as docs-only changes. Record a precise exemption in the implementation notes naming the deliverable, the reason, and the lower-layer test owner instead of creating a ritual test.

Why does my acceptance scenario pass without a ROM dump?

A scenario that skips due to a missing dump was never observed red and proves nothing. Run the acceptance layer with its capabilities required so a missing dump or cold cache fails loudly, or record the deliverable as unverified.

Can I fake internal components in acceptance tests?

No. Fake only true host boundaries like audio output, screen fades, wall clock, and save-root location with deterministic recording adapters. Never fake maps, scripts, actors, messages, collision, transitions, or saves, and never hand-assemble session internals.