acceptance-standard-definition

Convert desired behavior into falsifiable Given/When/Then acceptance criteria with evidence types.

4|Updated May 16, 2026
One-click install
npx skills add https://github.com/machenjie/rd-skills --skill acceptance-standard-definition
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: acceptance-standard-definition
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/acceptance-standard-definition
Command: npx skills add https://github.com/machenjie/rd-skills --skill acceptance-standard-definition

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps teams replace vague or subjective acceptance language with clear, falsifiable “done” criteria backed by evidence, so completion can be proven and verified rather than argued.

Core Features & Use Cases

  • Evidence-first acceptance criteria: Forces each criterion to specify Given/When/Then plus an evidence type that can be reproduced and reviewed.
  • Covers positive, negative, and recovery paths: Ensures denials, error handling, regression, and operational recovery are included proportionally to risk.
  • Non-functional standards with measurable thresholds: Prevents “fast/secure/robust” claims from slipping through without numeric thresholds, named controls, or standards references.
  • Traceability and scope requirements: Requires every criterion to trace to a scenario/requirement id and to define the applicable scope (data, load, environment, devices, tenants).
  • Routing and handoff alignment: Provides selection rules and explicitly hands off to specialized gates for test strategy, security/privacy, SLOs, performance thresholds, and release gating.

Quick Start

Ask the acceptance-standard-definition capability to convert your current acceptance criteria (or lack of them) into a falsifiable set of Given/When/Then standards with explicit evidence artifacts and release-blocking decisions.

Frequently Asked Questions about acceptance-standard-definition

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

FAQPage Schema
How do I write falsifiable acceptance criteria for non-functional requirements?

Falsifiable acceptance criteria require Given/When/Then structures specifying observable evidence types and scoped numeric thresholds. Replace subjective non-functional claims with measurable thresholds, named controls, and standards references that can be reproduced and reviewed.

What is the best way to define verifiable done standards for software changes?

Verifiable done standards are defined by converting desired behavior into objective, traceable Given/When/Then criteria. Each standard must include unacceptable outcomes, named evidence types, and trace back to a specific scenario or requirement ID to prove completion.

How do I include error recovery and permission denial paths in acceptance criteria?

Include error recovery and permission denial paths by creating distinct acceptance criteria that cover negative scenarios. Define the exact unacceptable outcomes and required observable evidence for denials, error handling, and operational recovery proportionate to risk.

How do acceptance criteria traceability and release-blocking gates work together?

Acceptance criteria traceability links each Given/When/Then standard to a specific scenario or requirement ID. Release-blocking gates use this traceability alongside named evidence artifacts and scoped thresholds to prevent deployment if verification fails.

When do I need to define scoped thresholds for test evidence in quality gates?

You need to define scoped thresholds for test evidence when establishing quality gates across varying data, load, environments, devices, or tenants. Scoping ensures the non-functional verification and observable evidence remain valid across applicable contexts.