skills.rest
levnikolaevich
levnikolaevichCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

ln-42-acceptance-test-builder

Creates, updates, consolidates, and runs acceptance tests using project-native tooling.

556|83|Updated Oct 24, 2025
Search Tags:#Oracle#ci#acceptance testing#Test automation#End-to-End Tests#Quality Assurance#test portfolio
One-click install
npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-42-acceptance-test-builder
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ln-42-acceptance-test-builder
Source: https://github.com/levnikolaevich/claude-code-skills/tree/main/plugins/testing-suite/skills/ln-42-acceptance-test-builder
Command: npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-42-acceptance-test-builder

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Maintaining a trustworthy acceptance-test portfolio is hard: teams accumulate redundant tests, encode oracles copied from the implementation, and claim coverage without executable evidence. This Skill enforces an evidence-driven workflow that builds the smallest reliable acceptance-test portfolio for stated requirements through user- or external-system-observable boundaries.

Core Features & Use Cases

  • Portfolio decisions, not just additions: Every affected test gets an explicit KEEP, ADD, UPDATE, MERGE, DELETE, or NO_TEST decision, with consolidation and retirement treated as first-class outcomes.
  • Independent oracles and reproducible evidence: Expected behavior is derived from requirements, contracts, or specifications rather than the implementation under test, with deterministic setup, cleanup, and rerun behavior.
  • Strict execution contract: A checkbox-based Definition of Done tracks every step as PROVEN, CLEARED, or UNPROVEN, and final verdicts (COMPLETE, INCOMPLETE, BLOCKED) never overclaim product correctness.
  • Use Case: After adding a password-reset API endpoint, use this Skill to inventory existing auth tests, design an end-to-end scenario against a disposable environment, implement it with the project's native runner, and produce a requirements matrix mapping each acceptance criterion to executed evidence.

Quick Start

Ask the agent to build acceptance tests for the new password-reset endpoint using the project's existing test runner and report the executed evidence.

Frequently Asked Questions about ln-42-acceptance-test-builder

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

FAQPage Schema
How do I write acceptance tests for a new feature?▼

Map each requirement to an observable boundary such as UI, API, CLI, or durable state, then define the protected outcome, independent oracle, setup, and cleanup for each scenario. Implement tests in the project's existing layout and runner, and execute the smallest scenario first before the full suite.

How to decide whether to add, update, merge, or delete an acceptance test?▼

Treat each test as a portfolio decision based on impact, plausible failure, uniqueness, trust, and maintenance cost. Merge or delete only when all still-required behavior, failure modes, and oracle strength remain covered by retained evidence; otherwise keep, add, or update.

Should acceptance tests use mocks or real dependencies?▼

Use real dependencies or approved emulators whenever mocks would bypass the behavior under acceptance. Pin versions, verify readiness and reset behavior, and reserve narrower contract boundaries for cases where they prove the terminal outcome more deterministically.

What should I do when an acceptance test exposes a product bug?▼

Stop modifying the implementation, retain the failing acceptance evidence, and report the smallest reproduction. The skill's scope is test evidence only; repairing product code or weakening assertions to force a pass is explicitly prohibited.

When are snapshot or golden-file tests appropriate for acceptance testing?▼

Use golden files only for deterministic, reviewable contracts where expectations are derived from an independent specification. Updating expected output is a specification change, not verification, and nondeterministic output should be asserted through stable invariants instead.

Related Skills

Explore More Software Engineering Skills→
osovvosovv
11

vv-plan

Generate structured implementation plans from approved spec.xml files.

Community
Advanced
ylxmf2005ylxmf2005
11

acceptance-review-lead

Review delivery evidence against acceptance criteria and issue a verdict.

Community
Advanced
CodeAlive-AICodeAlive-AI
119

bug-fix-protocol

Pair minimal code fixes with failing tests and testing-system audits.

Official
Advanced
Andreicr1Andreicr1

testing-reviewer

Evaluate code diffs for test coverage and behavioral verification.

Community
Advanced