菜单
Add acceptance tests under a functional spec in a ***plain spec file. Use when the user wants to add verification criteria for a specific functional spec, or after adding a functional spec that needs testable success criteria.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Authors and structures professional-grade agent skills following the agentskills.io spec. Use when creating new skill directories, drafting procedural instructions, or optimizing metadata for discoverability. Don't use for general documentation, non-agentic library code, or README files.
Add a concept to the ***definitions*** section of a ***plain spec file. Use when the user wants to define a new concept, entity, or domain term in a .plain file.
End-to-end feature addition on an existing ***plain project: runs a short feature-intent interview, then takes the confirmed request and, one question at a time, incrementally writes ***plain specs (concepts, implementation reqs, functional specs, test reqs, acceptance tests) to disk — asking, authoring, and reviewing per functionality — then closes with a plain-healthcheck gate. Use when the user wants to add a feature to an existing project. Not for bootstrapping a new project from scratch (use forge-plain) or for editing generated code (the .plain specs are the source of truth).
Add a single functional spec to the ***functional specs*** section of a ***plain spec file. Use whenever exactly one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author a new functional spec. Every new entry under ***functional specs*** must go through either this skill or `add-functional-specs` (the bulk variant for adding multiple specs in one pass); hand-authoring functional specs without invoking one of these skills is forbidden.
Add multiple functional specs to the ***functional specs*** section of a ***plain spec file in a single batch. Use whenever more than one new functional spec is being added — whether the user explicitly asks, or another skill/workflow (e.g. forge-plain, add-feature) needs to author several specs in one pass. Bulk-writing or hand-authoring functional specs without invoking this skill is forbidden; for adding a single spec, use add-functional-spec instead.
Add an implementation requirement to the ***implementation reqs*** section of a ***plain spec file. Use when the user wants to add non-functional requirements like technology choices, architectural constraints, coding standards, data formats, error handling strategies, or any HOW-to-build guidance to a .plain file.
| name | add-acceptance-test |
| description | Add acceptance tests under a functional spec in a ***plain spec file. Use when the user wants to add verification criteria for a specific functional spec, or after adding a functional spec that needs testable success criteria. |
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
.plain file and the functional spec to attach the acceptance test to. If ambiguous, ask the user.***test reqs*** section (acceptance tests are implemented according to test reqs).***acceptance tests*** subsection.add-functional-spec skill and warrants testable success criteria.Acceptance tests are nested under the functional spec they verify, using a ***acceptance tests*** subsection:
***functional specs***
- :Task: items are processed in batches of 100.
***acceptance tests***
- Processing 250 :Task: items should result in 3 batches.
- Each batch should contain at most 100 items.
Key formatting rules:
***acceptance tests*** header is indented under the functional spec it belongs to.***acceptance tests*** header.An acceptance test is essentially an example that illustrates the functional spec — it clarifies intent by showing a concrete scenario. It may imply minor code changes, but those should not be substantial. The acceptance test must be consistent with the functional spec it is nested under. If the acceptance test asserts behavior that contradicts, narrows, or extends the functional spec in ways not implied by it, the system will reject it as a conflicting acceptance test. Before writing, re-read the parent functional spec and ensure every assertion in the acceptance test is a direct, logical consequence of what the spec states.
Functional spec:
- :Resource: items are returned sorted by creation date in descending order.
Good (consistent):
- The first :Resource: in the response should have the most recent creation date.
Bad (contradicts the spec — the spec says descending, not ascending):
- The first :Resource: in the response should have the oldest creation date.
Bad (extends beyond the spec — the spec says nothing about limiting results):
- The response should contain at most 50 :Resource: items.
Each acceptance test verifies a specific, observable aspect of the functional spec it's nested under. Do not test behavior from other functional specs.
Every acceptance test must describe a concrete, verifiable outcome — not a vague quality. The test should be implementable as an automated conformance test.
Good: - The response should contain exactly 3 items.
Bad: - The response should be correct.
Like functional specs, acceptance tests must be written in terms of behavior and outcomes — not language-specific constructs.
Acceptance tests extend conformance tests and are implemented according to the ***test reqs*** specification. They do not replace test reqs — they add spec-specific verification on top of the general testing framework defined there.
***acceptance tests*** indented under the spec)