verifying-acceptance-criteria
Skill118 starsChanged 2 months agoMITView on GitHub
Compares implementation evidence against acceptance criteria and shows what is met, partial, missing, or untestable. Use when checking feature readiness, preparing QA sign-off, or turning criteria into a concrete verification matrix without inventing missing behavior.
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill when readiness depends on evidence rather than optimism.
- Distinctive: line 15
verify a feature against acceptance criteria before sign-off
- Distinctive: line 26
Evidence beats intuition: - every verdict should point to observable code, UI, API behavior, logs, or test evidence.
- Distinctive: line 39
If either side is missing, ask for it before continuing.
- Very specific: line 45
If a criterion mixes multiple expectations, split it.
- Very specific: line 46
If a criterion is vague, keep it but mark it as a likely Untestable candidate until evidence proves otherwise.
- Distinctive: line 73
Do not collapse these into a single optimistic conclusion.
- Distinctive: line 74
If there are meaningful gaps, call them out plainly.
- Distinctive: line 82
add or adjust tests
- Very specific: line 85
Use ./resources/ac-verification-template.md when possible.
- Distinctive: line 110
every meaningful criterion has a stable ID
- Distinctive: line 112
every verdict points to evidence or a clearly stated gap
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verifying Acceptance Criteria
Use this skill when readiness depends on evidence rather than optimism. It helps compare the stated contract of a feature with what the implementation actually proves today.
When to Use
- verify a feature against acceptance criteria before sign-off
- review a build, PR, or live environment for readiness
- separate met requirements from partial or missing behavior
- expose criteria that are too vague to verify honestly
- prepare a QA-ready verification matrix for release or handoff
Verification Rules
- Source of truth must be explicit - story, AC list, PRD slice, or ticket text.
- Do not fill requirement gaps silently - unclear criteria become
Untestable, not invented behavior. - One criterion, one verdict - split compound criteria into atomic items before judging them.
- Evidence beats intuition - every verdict should point to observable code, UI, API behavior, logs, or test evidence.
- Partial is a valid status - it is better than pretending a near-miss is complete.
Workflow
Phase 0: Gather both sides of the comparison
Collect:
- the acceptance criteria or equivalent source of truth
- implementation evidence such as code changes, screenshots, API responses, a running URL, or exploratory notes
- the environment or build under review
If either side is missing, ask for it before continuing.
Phase 1: Normalize the criteria
Convert the input into atomic criteria with stable IDs such as AC-001, AC-002, and AC-003.
If a criterion mixes multiple expectations, split it.
If a criterion is vague, keep it but mark it as a likely Untestable candidate until evidence proves otherwise.
Phase 2: Verify each criterion
Use these verdicts:
| Status | Meaning |
| Met | The implementation clearly satisfies the criterion |
| Partial | Some of the criterion is implemented, but not all of it |
| Not Met | No convincing evidence of implementation exists |
| Untestable | The criterion is too vague or ambiguous to verify honestly |
For every criterion, capture:
- the verdict
- the evidence
- any assumptions, blockers, or follow-up questions
Phase 3: Summarize readiness
Group the result into:
- Ready - criteria clearly met
- Needs follow-up - partial or not met
- Needs clarification - untestable or ambiguous
Do not collapse these into a single optimistic conclusion. If there are meaningful gaps, call them out plainly.
Phase 4: Recommend the next move
Depending on what the matrix shows:
- fix missing behavior
- clarify the criteria upstream
- add or adjust tests
- re-run verification after evidence improves
Use ./resources/ac-verification-template.md when possible.
Common Failure Modes
- verifying against a fuzzy paraphrase instead of the real acceptance criteria
- treating partial implementation as complete
- hiding ambiguity in prose instead of using an explicit status
- failing to cite evidence for the verdict
- collapsing multiple criteria into one vague pass/fail judgment
Resource Map
./resources/ac-verification-template.md- structure for the verification matrix and readiness summary
Related Skills
analyzing-regression-scope- when change impact needs tactical retest planningdesigning-functional-tests- when unmet criteria need new scenarios or manual casesrequirements-test-coverage-mapper- when full traceability across test levels is requiredreporting-bugs- when a failed criterion should become a defect ticket
Definition of Done
This skill is complete when:
- every meaningful criterion has a stable ID
- each criterion has an explicit status
- every verdict points to evidence or a clearly stated gap
- ambiguity is visible instead of hidden
- the summary makes sign-off risk obvious
In this repository51 other files it gives its agents.
- analyzing-quality-metricsSkill
- analyzing-regression-scopeSkill
- api-playwright-test-developerSkill
- assessing-comprehension-debtSkill
- assessing-release-readinessSkill
- attesting-manual-verificationSkill
- auditing-accessibilitySkill
- code-review-advancedSkill
- code-reviewSkill
- communicating-quality-findingsSkill
- creating-custom-agentsSkill
- creating-hooksSkill
- creating-instructionsSkill
- creating-orchestration-packsSkill
- creating-pluginsSkill
- creating-promptsSkill
- creating-skillsSkill
- deriving-a-quality-contractSkill
- designing-functional-testsSkill
- designing-test-dataSkill
- documenting-test-suitesSkill
- generating-quality-gate-workflowsSkill
- governing-quality-waiversSkill
- handling-sensitive-test-dataSkill
- migrating-tests-to-playwrightSkill
- mocking-network-and-timeSkill
- planning-exploratory-testingSkill
- prd-generatorSkill
- recording-change-intentSkill
- reporting-bugsSkill
- requirements-test-coverage-mapperSkill
- reviewing-ai-output-groundednessSkill
- running-visual-regression-testsSkill
- scoping-change-relevanceSkill
- static-code-analysis-typescriptSkill
- tech-debt-analysisSkill
- test-driven-development-quickSkill
- test-driven-developmentSkill
- testing-agent-skillsSkill
- testing-api-contractsSkill
- testing-application-securitySkill
- testing-llm-featuresSkill
- testing-llm-guardrailsSkill
- testing-performance-and-loadSkill
- tracing-requirements-to-codeSkill
- tracking-quality-trendsSkill
- unslop-answersSkill
- unslop-testsSkill
- verifying-change-coverageSkill
- writing-unit-tests-quickSkill
- writing-unit-testsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.