qa-acceptance

Name: qa-acceptance
Author: getpaperclipai

5stars1forks

How to install qa-acceptance?

getpaperclipai/paperclip/qa-acceptance

$npx -y skills add getpaperclipai/paperclip --skill qa-acceptance

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# QA Acceptance
2
3	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.
4
5	## When to use
6
7	- A feature change is heading to QA and needs a written validation plan.
8	- A reviewer is asked to verify a PR that touches user-visible behavior.
9	- An incident postmortem requires a regression check before reopen-prevention.
10	- A release candidate needs a pre-cut smoke pass.
11
12	## When not to use
13
14	- The change is unit-test-only (utility refactor, internal naming). Acceptance criteria are unnecessary churn.
15	- You are asked to write tests against API contracts. Use contract testing, not feature QA.
16
17	## Acceptance criteria format
18
19	Each criterion is a single, independently-verifiable statement:
20
21	```md
22	- Given <starting state>, when <action>, then <observable outcome>.
23	```
24
25	Example:
26
27	```md
28	- Given a CSV export with 0 rows, when the user clicks Export, then the file downloads with only the header row and the UI shows "Exported 0 rows".
29	```
30
31	Avoid criteria that combine multiple `when`s or `then`s. Split them.
32
33	## What every plan must cover
34
35	1. Golden path. The most common successful flow, end to end.
36	2. Empty and minimum states. Zero items, one item, missing optional inputs.
37	3. Boundary inputs. Max length strings, max numeric values, unicode, RTL text where applicable.
38	4. Error states. Network failure, permission denied, validation failures, conflict (409), not found (404).
39	5. Concurrency and ordering. Two users acting at once, race against background jobs, refresh during mutation.
40	6. Performance envelope. The largest realistic input the change must handle without UI hangs or timeouts.
41	7. Backward compatibility. Existing data, existing URLs, persisted user preferences continue to work.
42	8. Telemetry and audit. Events, logs, or activity entries the change is supposed to emit.
43
44	If a section is genuinely not applicable, write "N/A: <why>" — do not silently omit.
45
46	## Evidence
47
48	Each criterion needs evidence on the verification pass:
49
50	- Screenshot or short clip for UI behavior.
51	- Copied console / network output for API behavior.
52	- Log snippet or activity row for telemetry.
53	- Timing measurement for performance criteria.
54
55	"Looks good to me" without evidence is not a pass.
56
57	## Quarantine and follow-up
58
59	- A failing criterion blocks acceptance unless explicitly waived by the owner with a tracked follow-up issue.
60	- "Known issue" without a linked follow-up is not a waiver.
61	- If you add a new criterion mid-pass, restart the pass — partial coverage hides regressions.
62
63	## Handoff back to the author
64
65	Return the validation plan with three sections:
66
67	- Pass. Criteria that passed, with one-line evidence summaries.
68	- Fail. Criteria that failed, with the exact reproduction.
69	- Blocked. Criteria you could not run, with why.
70
71	The author owns turning failures into either fixes or accepted deferrals.
72
73	## Anti-patterns
74
75	- Acceptance phrased as test plan ("write a Cypress test for X"). Acceptance is what is true after the change ships; tests are how you check.
76	- Criteria that depend on inspecting implementation details (selectors, query plans). Stay observable.
77	- Long checklists with no priority. Mark must-pass criteria distinctly from nice-to-have.
78	- Validation reports that say "passed" with no evidence. Reviewers cannot audit those.

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

qa-acceptance

5stars1forks

View on GitHub

How to install qa-acceptance?

getpaperclipai/paperclip/qa-acceptance

$npx -y skills add getpaperclipai/paperclip --skill qa-acceptance

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# QA Acceptance
2
3	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.
4
5	## When to use
6
7	- A feature change is heading to QA and needs a written validation plan.
8	- A reviewer is asked to verify a PR that touches user-visible behavior.
9	- An incident postmortem requires a regression check before reopen-prevention.
10	- A release candidate needs a pre-cut smoke pass.
11
12	## When not to use
13
14	- The change is unit-test-only (utility refactor, internal naming). Acceptance criteria are unnecessary churn.
15	- You are asked to write tests against API contracts. Use contract testing, not feature QA.
16
17	## Acceptance criteria format
18
19	Each criterion is a single, independently-verifiable statement:
20
21	```md
22	- Given <starting state>, when <action>, then <observable outcome>.
23	```
24
25	Example:
26
27	```md
28	- Given a CSV export with 0 rows, when the user clicks Export, then the file downloads with only the header row and the UI shows "Exported 0 rows".
29	```
30
31	Avoid criteria that combine multiple `when`s or `then`s. Split them.
32
33	## What every plan must cover
34
35	1. Golden path. The most common successful flow, end to end.
36	2. Empty and minimum states. Zero items, one item, missing optional inputs.
37	3. Boundary inputs. Max length strings, max numeric values, unicode, RTL text where applicable.
38	4. Error states. Network failure, permission denied, validation failures, conflict (409), not found (404).
39	5. Concurrency and ordering. Two users acting at once, race against background jobs, refresh during mutation.
40	6. Performance envelope. The largest realistic input the change must handle without UI hangs or timeouts.
41	7. Backward compatibility. Existing data, existing URLs, persisted user preferences continue to work.
42	8. Telemetry and audit. Events, logs, or activity entries the change is supposed to emit.
43
44	If a section is genuinely not applicable, write "N/A: <why>" — do not silently omit.
45
46	## Evidence
47
48	Each criterion needs evidence on the verification pass:
49
50	- Screenshot or short clip for UI behavior.
51	- Copied console / network output for API behavior.
52	- Log snippet or activity row for telemetry.
53	- Timing measurement for performance criteria.
54
55	"Looks good to me" without evidence is not a pass.
56
57	## Quarantine and follow-up
58
59	- A failing criterion blocks acceptance unless explicitly waived by the owner with a tracked follow-up issue.
60	- "Known issue" without a linked follow-up is not a waiver.
61	- If you add a new criterion mid-pass, restart the pass — partial coverage hides regressions.
62
63	## Handoff back to the author
64
65	Return the validation plan with three sections:
66
67	- Pass. Criteria that passed, with one-line evidence summaries.
68	- Fail. Criteria that failed, with the exact reproduction.
69	- Blocked. Criteria you could not run, with why.
70
71	The author owns turning failures into either fixes or accepted deferrals.
72
73	## Anti-patterns
74
75	- Acceptance phrased as test plan ("write a Cypress test for X"). Acceptance is what is true after the change ships; tests are how you check.
76	- Criteria that depend on inspecting implementation details (selectors, query plans). Stay observable.
77	- Long checklists with no priority. Mark must-pass criteria distinctly from nice-to-have.
78	- Validation reports that say "passed" with no evidence. Reviewers cannot audit those.

People who liked this also viewed

6 picks

Type