ln-42-acceptance-test-builder

Name: ln-42-acceptance-test-builder
Author: levnikolaevich

520stars73forks

How to install ln-42-acceptance-test-builder?

levnikolaevich/claude-code-skills/ln-42-acceptance-test-builder

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-42-acceptance-test-builder

Installs into the current project.

Summary

Creates and runs reproducible acceptance tests for stated requirements using project-native tooling. Use when executable acceptance evidence is needed; not for audits or product fixes.

Files · 1

View on GitHub

SKILL.md

1	# Acceptance Test Builder
2
3	Goal: Create executable evidence that stated requirements work through the boundary users or external systems observe. Modify only the approved test and test-documentation scope. If a test exposes a product defect, preserve the evidence and report it instead of repairing production code.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Workspace safety \| Git status, diff, repository instructions, and branch or worktree inspection \| Always before editing \| Stop when user changes cannot be separated safely \|
13	\| Existing test conventions \| File listing, search, manifests, runner configuration, CI, and focused reads \| Selecting the project-native runner, layout, fixtures, and commands \| Follow the nearest maintained test pattern \|
14	\| Behavior and wiring \| Language server or host-native code intelligence \| Locating observable entrypoints, registration, consumers, and state boundaries \| Narrow search plus direct inspection \|
15	\| Test implementation \| Native editing tools and project generators \| Creating tests, fixtures, helpers, and narrowly required test documentation \| Minimal project-consistent files; never hand-edit generated state \|
16	\| Observable execution \| Repository-defined shell commands, browser, API client, CLI, or disposable integration environment \| Proving UI, protocol, command, or durable state outcomes \| Return `INCOMPLETE` with the exact missing check \|
17	\| External contract \| Official version-matched documentation or specification \| Expected behavior depends on a current external API or standard \| Mark it `UNVERIFIED`; do not encode a guessed oracle \|
18
19	Never run acceptance tests against production or an unapproved external target. Do not deploy, publish, migrate shared data, rotate credentials, or accept changed output merely to make a test pass.
20
21	## Evidence Rules
22
23	- Derive expected behavior from requirements, public contracts, examples, invariants, or an independent reference; never from the implementation calculation being tested.
24	- Prefer a terminal durable or user-visible outcome over an intermediate status, mock call, log line, or internal method result.
25	- Use golden files or snapshots only for deterministic, reviewable contracts. Updating expected output is a specification change, not test verification.
26	- Make setup, data allocation, execution, cleanup, and rerun behavior reproducible; preserve the first failure before retries or cleanup obscure it.
27	- A passing command proves only the environment and scenarios it actually exercised. State every excluded cell and unavailable boundary.
28
29	## Checklist
30
31	### 1. Establish the Change Boundary
32
33	- [ ] Resolve the requirements, acceptance criteria, actor, observable outcome, explicit non-goals, allowed test paths, and allowed test-documentation paths.
34	- [ ] Read applicable repository instructions and inspect Git state, untracked files, generated areas, and existing user changes before editing.
35	- [ ] Detect the project-native runner, directory layout, naming, fixtures, setup, cleanup, environment configuration, and CI invocation.
36	- [ ] Map each requirement to the boundary that can prove it: UI, API, CLI, message, integration, file, or durable state.
37	- [ ] Identify credentials, services, accounts, ports, devices, browsers, datasets, and destructive effects required by the scenarios.
38	- [ ] Return `BLOCKED` before editing when no safe target, reliable expected contract, or separable workspace exists.
39
40	### 2. Design Reproducible Acceptance Evidence
41
42	- [ ] Define setup, action, terminal outcome, independent oracle, expected evidence, and cleanup for every requirement.
43	- [ ] Use the lowest production-shaped boundary that still proves the requirement; do not replace acceptance evidence with a unit-level implementation check.
44	- [ ] Include material invalid, authorization, boundary, partial-failure, retry, idempotency, recovery, and compatibility behavior.
45	- [ ] Allocate unique or namespaced test data and control clock, randomness, locale, ordering, and concurrency where they affect reproducibility.
46	- [ ] Use real dependencies or approved emulators when mocks would bypass the behavior under acceptance; pin versions and verify readi

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Acceptance Test Builder

**Goal:** Create executable evidence that stated requirements work through the boundary users or external systems observe. Modify only the approved test and tes

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

ln-42-acceptance-test-builder

520stars73forks

View on GitHub

How to install ln-42-acceptance-test-builder?

levnikolaevich/claude-code-skills/ln-42-acceptance-test-builder

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-42-acceptance-test-builder

Installs into the current project.

Summary

Creates and runs reproducible acceptance tests for stated requirements using project-native tooling. Use when executable acceptance evidence is needed; not for audits or product fixes.

Files · 1

View on GitHub

SKILL.md

1	# Acceptance Test Builder
2
3	Goal: Create executable evidence that stated requirements work through the boundary users or external systems observe. Modify only the approved test and test-documentation scope. If a test exposes a product defect, preserve the evidence and report it instead of repairing production code.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Workspace safety \| Git status, diff, repository instructions, and branch or worktree inspection \| Always before editing \| Stop when user changes cannot be separated safely \|
13	\| Existing test conventions \| File listing, search, manifests, runner configuration, CI, and focused reads \| Selecting the project-native runner, layout, fixtures, and commands \| Follow the nearest maintained test pattern \|
14	\| Behavior and wiring \| Language server or host-native code intelligence \| Locating observable entrypoints, registration, consumers, and state boundaries \| Narrow search plus direct inspection \|
15	\| Test implementation \| Native editing tools and project generators \| Creating tests, fixtures, helpers, and narrowly required test documentation \| Minimal project-consistent files; never hand-edit generated state \|
16	\| Observable execution \| Repository-defined shell commands, browser, API client, CLI, or disposable integration environment \| Proving UI, protocol, command, or durable state outcomes \| Return `INCOMPLETE` with the exact missing check \|
17	\| External contract \| Official version-matched documentation or specification \| Expected behavior depends on a current external API or standard \| Mark it `UNVERIFIED`; do not encode a guessed oracle \|
18
19	Never run acceptance tests against production or an unapproved external target. Do not deploy, publish, migrate shared data, rotate credentials, or accept changed output merely to make a test pass.
20
21	## Evidence Rules
22
23	- Derive expected behavior from requirements, public contracts, examples, invariants, or an independent reference; never from the implementation calculation being tested.
24	- Prefer a terminal durable or user-visible outcome over an intermediate status, mock call, log line, or internal method result.
25	- Use golden files or snapshots only for deterministic, reviewable contracts. Updating expected output is a specification change, not test verification.
26	- Make setup, data allocation, execution, cleanup, and rerun behavior reproducible; preserve the first failure before retries or cleanup obscure it.
27	- A passing command proves only the environment and scenarios it actually exercised. State every excluded cell and unavailable boundary.
28
29	## Checklist
30
31	### 1. Establish the Change Boundary
32
33	- [ ] Resolve the requirements, acceptance criteria, actor, observable outcome, explicit non-goals, allowed test paths, and allowed test-documentation paths.
34	- [ ] Read applicable repository instructions and inspect Git state, untracked files, generated areas, and existing user changes before editing.
35	- [ ] Detect the project-native runner, directory layout, naming, fixtures, setup, cleanup, environment configuration, and CI invocation.
36	- [ ] Map each requirement to the boundary that can prove it: UI, API, CLI, message, integration, file, or durable state.
37	- [ ] Identify credentials, services, accounts, ports, devices, browsers, datasets, and destructive effects required by the scenarios.
38	- [ ] Return `BLOCKED` before editing when no safe target, reliable expected contract, or separable workspace exists.
39
40	### 2. Design Reproducible Acceptance Evidence
41
42	- [ ] Define setup, action, terminal outcome, independent oracle, expected evidence, and cleanup for every requirement.
43	- [ ] Use the lowest production-shaped boundary that still proves the requirement; do not replace acceptance evidence with a unit-level implementation check.
44	- [ ] Include material invalid, authorization, boundary, partial-failure, retry, idempotency, recovery, and compatibility behavior.
45	- [ ] Allocate unique or namespaced test data and control clock, randomness, locale, ordering, and concurrency where they affect reproducibility.
46	- [ ] Use real dependencies or approved emulators when mocks would bypass the behavior under acceptance; pin versions and verify readi

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Acceptance Test Builder

**Goal:** Create executable evidence that stated requirements work through the boundary users or external systems observe. Modify only the approved test and tes

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type