Agent skill · operations · paperclipai
qa-acceptance
Produce QA acceptance criteria and a manual validation plan for a feature change — golden path, edge cases, error states, performance limits, and explicit pass/fail evidence.
Why this skill is useful
Provides a detailed framework for producing QA acceptance criteria that enhances the AI's ability to generate specific validation plans for feature changes.
What it needs
About 2k tokens when loaded. Last updated 2026-08-07. 75,771 stars on the source repository.
What this skill does
QA Acceptance Write acceptance criteria that a reviewer can run against the running app and decide pass or fail without asking the author. The criteria are the contract — automated tests cover correctness, QA covers feature-level behavior. When to use A feature change is heading to QA and needs a written validation plan. A reviewer is asked to verify a PR that touches user-visible behavior. An incident postmortem requires a regression check before reopen-prevention. A release candidate needs a pre-cut smoke pass. When not to use The change is unit-test-only (utility refactor, internal naming). Acceptance criteria are unnecessary churn. You are asked to write tests against API contracts. Use contract testing, not feature QA. Acceptance criteria format Each criterion is a single, independently-verifiable statement: Example: Avoid criteria that combine multiple whens or thens. Split them. What every plan must cover 1. Golden path. The most common successful flow, end to end. 2. Empty and minimum states. Zero items, one item, missing optional inputs. 3. Boundary inputs. Max length strings, max numeric values, unicode, RTL text where applicable. 4. Error states. Network failure, permission denied, validation failures, conflict (409), not found (404). 5. Concurrency and ordering. Two users acting at once, race against background jobs, refresh during mutation. 6. Performance envelope. The largest realistic input the change must handle without UI hangs or timeouts. 7. Backward compatibility. Existing data, existing URLs, persisted user preferences continue to work. 8. Telemetry and audit. Events, logs, or activity entries the change is supposed to emit. If a section is genuinely not applicable, write "N/A: <why>" — do not silently omit. Evidence Each criterion needs evidence on the verification pass: Screenshot or short clip for UI behavior. Copied console / network output for API behavior. Log snippet or activity row for telemetry. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills paperclipai/qa-acceptance