菜单
Write testable acceptance criteria and acceptance tests for requirements using Given/When/Then, checklist, and rule-based formats. Use when defining the conditions that prove a requirement is correctly implemented.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/lennney/gate-all-skills --skill acceptance-criteria命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
"AI 审查 / AI code review. 用户说"帮我审查代码"、"review 一下"、"看看这段有没有问题"时加载。在后台检查 bug、安全、性能、代码风格，然后告诉用户结果。"
"AI 编码 / AI coding. 用户说"帮我写个组件"、"实现这个功能"、"写个 API 路由"时加载。先问清需求，在后台实现，完成后自动调 /ai-code-review 审查。"
"AI 调试 / AI debugging. 用户说"帮我 debug"、"报错了"、"这个 bug 怎么修"、"抛异常了"时加载。让用户描述问题，你在后台分析根因并修复。"
基于 SOC 职业分类
正在显示 SKILL.md
| name | acceptance-criteria |
| description | Write testable acceptance criteria and acceptance tests for requirements using Given/When/Then, checklist, and rule-based formats. Use when defining the conditions that prove a requirement is correctly implemented. |
| intent | Create acceptance criteria that define the specific, testable conditions under which a requirement is considered satisfied. Covers three formats (Given/When/Then, checklist, rule-based), SMART criteria for requirements, and the separation between acceptance criteria (conditions) and acceptance tests (procedures). Use this to close the gap between "what does this requirement mean?" and "how do we prove it works?" |
| type | component |
| theme | re-artifacts |
| best_for | ["Defining done for user stories and requirements","Creating testable conditions for functional and non-functional requirements","Bridging the gap between requirements and test cases"] |
| scenarios | ["Developers keep asking what 'done' means for this requirement","I need to write acceptance criteria that QA can turn into test cases"] |
| estimated_time | 5-10 min per requirement |
| trigger | 需要定义功能完成标准 |
| input | PRD 文档 |
| output | 验收标准列表 |
| next | user-story |
| dependencies | prd-development |
Create acceptance criteria that define the specific, testable conditions under which a requirement is considered satisfied. Use this to close the gap between "what does this requirement mean?" and "how do we prove it works?"
This is not test case writing -- acceptance criteria define what to verify. Test cases define how to verify it. Acceptance criteria live in requirements; test cases live in test plans.
| Aspect | Acceptance Criteria | Acceptance Tests |
|---|---|---|
| What | Conditions for satisfaction | Procedures to verify conditions |
| Who writes | BA / Requirements Engineer | QA / Test Engineer |
| When | During requirements specification | During test planning |
| Format | Given/When/Then, checklists | Step-by-step test procedures with expected results |
| Lives in | SRS, user stories | Test plan, test management tool |
1. Given/When/Then (Gherkin) Best for behavior-driven scenarios with clear preconditions and triggers:
Given [precondition],
When [action],
Then [expected result].
2. Checklist Best for straightforward pass/fail conditions:
- [ ] [Condition that must be true]
- [ ] [Another condition that must be true]
3. Rule-Based Best for business rules with multiple examples:
Rule: [Business rule statement]
Example: [Input] -> [Expected output]
Example: [Different input] -> [Different expected output]
Every acceptance criterion should be:
Take your requirement (user story, shall statement, or use case step) and ask:
| Use This Format | When |
|---|---|
| Given/When/Then | The behavior depends on preconditions and has clear trigger/response |
| Checklist | Simple pass/fail conditions without complex preconditions |
| Rule-Based | A business rule with multiple scenarios or boundary conditions |
Given/When/Then example:
**Requirement:** CT.ALERT.EXPIRY.1 -- The system shall send an email
alert to the responsible lab technician when a chemical is 30 days
from expiration.
**Acceptance Criteria:**
AC-1: Given a chemical with expiration date exactly 30 days from today,
and a lab technician is assigned to its storage location,
When the daily alert job runs,
Then an email is sent to the assigned technician containing the
chemical name, CAS number, location, and expiration date.
AC-2: Given a chemical with expiration date exactly 30 days from today,
and no technician is assigned to its storage location,
When the daily alert job runs,
Then an email is sent to the lab manager instead.
AC-3: Given a chemical with status "Disposed,"
and expiration date is 30 days from today,
When the daily alert job runs,
Then no alert is sent for that chemical.
Checklist example:
**Requirement:** CT.CATALOG.SEARCH.1 -- Search for chemicals by name,
CAS number, location, or expiration date range.
**Acceptance Criteria:**
- [ ] Search by partial chemical name returns all matching records
- [ ] Search by exact CAS number returns the specific record
- [ ] Search by storage location returns all chemicals in that location
- [ ] Search by date range returns chemicals expiring within that range
- [ ] Combining multiple criteria narrows results (AND logic)
- [ ] Empty search results display "No chemicals found" message
- [ ] Search results display within 2 seconds for 50,000 records
Rule-based example:
**Requirement:** BR-002 -- Volume discount calculation
**Acceptance Criteria:**
Rule: Discount is calculated on per-SKU order quantity, not total order.
Example: 50 units of SKU-A -> 0% discount (below 100 threshold)
Example: 150 units of SKU-A -> 5% discount on all 150 units
Example: 50 units SKU-A + 100 units SKU-B -> 0% on A, 5% on B
Rule: Discount applies to pre-tax unit price.
Example: SKU-A at $10/unit, 200 units -> $10 * 0.95 * 200 = $1,900
For each acceptance criterion, verify:
Walk through acceptance criteria with:
See examples/sample.md for complete acceptance criteria sets.
Symptom: All acceptance criteria describe what the system should do. None describe what it should not do.
Consequence: Error paths, edge cases, and security concerns are not tested.
Fix: For every positive criterion, ask "What should NOT happen?" Add at least one negative criterion per requirement.
Symptom: "System responds quickly" or "Data is displayed correctly."
Consequence: Tester cannot determine pass/fail. "Quickly" to whom? "Correctly" by what standard?
Fix: Quantify: "Response within 2 seconds" and "Displays all 6 fields in the specified order."
Symptom: "The system uses PostgreSQL to store the record" or "The API returns a 200 status code."
Consequence: Criteria are coupled to implementation. If the database changes, the criteria break even though behavior is the same.
Fix: Test behavior: "The record is retrievable after save" and "The system confirms successful submission."
user-story-re -- Acceptance criteria are part of every user storyuse-case -- Acceptance criteria can be derived from use case flowsbusiness-rule -- Rule-based criteria often implement business rulesrequirements-validation-process -- Acceptance criteria are validated during reviewSkill type: Component
Dependencies: None
Used by: user-story-re, requirements-validation-process