acceptance-checklist

Acceptance Checklist

After R&D submits for testing and before launch, the product team should be able to walk through item by item with a checklist, rather than signing off after a few impression-based clicks. This Skill breaks the PRD and delivery package into checkable acceptance items.

Scope of Use

• Applicable: Product walkthrough after R&D submits for testing (Sanity Check), functional acceptance before launch, and verification of visual and interaction fidelity.
• Not applicable: Writing test code or running automated tests (that is the testers' job); reviewing code quality; determining whether a version can be released.
• What this Skill produces is aproduct acceptancechecklist, not test cases—the two differ in granularity: test cases cover implementation branches, while the acceptance checklist coversuser-perceivable results。

Before Starting

1. Determine the feature name <feature-name>, locate docs/prd/<feature-name>/。
2. Read prd.md（Required）；prototype.html、demo.md read if present.
   • Without prd.md , do not hard-code a checklist based on the prototype—prompt the user to supply the PRD first, or explicitly mark that this acceptance has no requirements basis.
3. Extract the requirement numbers from the PRD (R1、R2...), acceptance criteria, out-of-scope list, and the status and exception inventory in the delivery package.

Breakdown Dimensions

Dimension	What It Covers	Default Priority
Core Flow	Whether the main path works: enter entry point → perform action → result is correct → status updates → viewable	P0
Boundaries and Exceptions	Network exceptions, timeouts, no permission, quota exhausted, non-compliant input, concurrent submission	P0 / P1
UI Fidelity	Whether the layout, copy, loading state, empty state, and interaction feedback of key pages are consistent with the PRD and prototype	P1 / P2
Data Tracking	Whether tracking for the core conversion funnel is triggered (only done when conditional acceptance applies)	P2

Do not write items that cannot be judged, such as "good experience" or "meets expectations." Every item must beindependently verifiable by a third party.

Deliverable

Write to docs/prd/<feature-name>/acceptance.md：

## <维度>
### 需求 R1 · <需求名>

- [ ] **<可验证的行为描述>**  `P0`
      - 预期：<看到什么算通过>
      - 依据：`prd.md` R1 验收标准第 2 条
      - 结果：☐ 通过  ☐ 未通过  ☐ 跳过

Each item must contain three things:a verifiable description、expected result、source of basis(pointing back to which PRD number). The source of basis is where the value of this checklist lies—when an item fails, you can directly locate whether the requirement was unclear or the implementation was not done.

When you need to walk through it by clicking in a browser

By default, produce markdown. If you want to check off items one by one in a browser and see pass-rate progress, have the AI generate a acceptance.md based onsingle-file HTML checklist; this Skill does not preset or depend on any frontend framework or local service.

Pre-delivery Check

• Every acceptance item can be independently verified by a third party, with no subjective statements.
• Every item has a source of basis, and the PRD entry it points to actually exists.
• Priorities are marked, and P0 items cover the main flow and major exceptions.
• prd.md 's "out-of-scope" content was not mistakenly included in the checklist.
• clearly indicates the dimensions not covered this time (for example, when there is no tracking data).

What not to do

• Do not write test code, and do not replace testing.
• Do not execute tests, and do not determine whether a version can be released.
• Do not reverse-engineer requirements from prototypes and treat them as acceptance criteria.
• Do not introduce external frameworks or local services that require a long-running process.

Next steps

After the walkthrough is completed, organize the failed items into a defect list by owner; if the failed items expose gaps in the requirements themselves, go back to grill-with-prd or prd-write to fill them in, rather than changing the criteria on the spot during the acceptance stage.