Convert the requirements/solution.md / requirements/prd.md 's acceptance criteria (AC) into executable, decidable, traceable manual test cases.
Inputs and Gates (must be observed)
REQUIRED SUB-SKILL: currently executing spec-context to obtain context, and echo in the conversation FEATURE_DIR=...(allowing (reuse)）。
- required reading of project-level memory：
project/memory/product.md、project/memory/tech.md、project/memory/glossary.md; if it cannot be read, you must writeCONTEXT GAP。 - Requirement-level minimum input：
{FEATURE_DIR}/requirements/solution.mdor{FEATURE_DIR}/requirements/prd.mdat least one must exist; otherwise stop and writeCONTEXT GAP。 - Mandatory template use：
usecase.mdmust directly use the use case templateassets/test_usercase_template.md(no inventing your own structure, no changing field names/section names).
Output (written to disk)
{FEATURE_DIR}/verification/usecase.md
Mandatory template (must be observed)
usecase.mdmust be generated according to the template (no inventing your own structure/field names/section names):assets/test_usercase_template.md
Content requirements
- Each test case must be filled in according to the template (at least the "Standard Test Case Template" section)
- Each step must have an observable expectation (can determine Pass/Fail/Blocked)
- Each test case must be traceable to an AC (pointing to
solution/prd）
Note:
- In the template, the status/execution history/defect ID fields are used to align with V4
report-*.md; execution results and defect references are governed byreport-*.md(do not add defect files/directories within the Spec Pack).
DoD self-check (V2-DoD)
- P0/P1 test cases are all "executable": preconditions and data are not missing
- Every step has an "expected result" (observable, decidable)
- AC coverage relationships are clear (at minimum, it can answer "which ACs are covered by which test cases")
- Each test case is filled in according to the
assets/test_usercase_template.mdtemplate (fields and sections are not missing)