spec-test-usecase

Original：🇨🇳 Chinese

Translated

Use when you need to generate or update `{FEATURE_DIR}/verification/usecase.md` (test cases) during the verification phase of the Spec Pack, and require AC traceability and a structure that supports automated script generation.

2installs

Sourcezixun-github/aisdlc

Added on2026-03-02

NPX Install

npx skill4agent add zixun-github/aisdlc spec-test-usecase

SKILL.md Content (Chinese)

View Translation Comparison →

Spec Test Cases (V2: Usecase)

Convert the acceptance criteria (AC) in

requirements/solution.md

requirements/prd.md

into an executable, determinable, traceable, machine-extractable manual test case structure.

Authoritative specification:

design/aisdlc_spec_verification.md

Hard Access Control (Must Comply)

Locate path first before reading/writing: You must first run
```
spec-context
```
to get and echo
```
FEATURE_DIR=...
```
; stop immediately if it fails, guessing paths is prohibited.

Must read project-level memory:

project/memory/product.md

project/memory/tech.md

project/memory/glossary.md

; write

CONTEXT GAP

if any of them cannot be read.

Minimum requirement-level input: At least one of
```
{FEATURE_DIR}/requirements/solution.md
```
or
```
{FEATURE_DIR}/requirements/prd.md
```
must exist; otherwise stop and write
```
CONTEXT GAP
```
.
Mandatory structuring: Each test case must meet the minimum structure of "ID/type/steps + assertion points/traceability/suite", free prose is not allowed as a replacement.
Unauthorized routing prohibited: Only output
```
ROUTER_SUMMARY
```
after completion, the next step is decided by
```
using-aisdlc
```
.

Red Flag Checklist (Stop if Any Item Occurs)

Start writing test cases without echoing
```
FEATURE_DIR=...
```
Try to use descriptions like "cover login/cover payment" to replace
```
TC-*
```
executable steps
Try to write "expected results" as subjective judgments (such as "looks normal") instead of observable assertion points
Try to use
```
TBD/to be supplemented
```
to replace AC traceability links

The Only Operation Method (PowerShell)

1) Get

FEATURE_DIR

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

2) Target Output Path

powershell

$out = Join-Path $FEATURE_DIR "verification/usecase.md"
Write-Host "OUTPUT=$out"

Test Case Structure (Mandatory, Automation Friendly)

Each test case must include:

Stable ID:
```
TC-<DOMAIN>-<NNN>
```
(example:
```
TC-AUTH-001
```
). Do not change the ID randomly after release.
Priority: P0 / P1 / P2
Type: UI / API / Integration / Regression (can be extended as needed, but must be enumerable)
Tags: Impact scope/module/risk (in array format)
Traceability: Link to at least 1 AC (from
```
solution/prd
```
)
Suite: Mark at least
```
smoke
```
/
```
regression
```
(you can also mark
```
targeted
```
if applicable)
Preconditions: Preparable and executable (including account/permission/switch/environment)
Test data: Provide sample values or generation methods ("prepare by yourself" is prohibited)
Steps: Numbered step by step; each step must include expected results (observable assertion points)
Post conditions/Cleanup: Must be clearly written when data will be polluted

Minimum Template (Single Test Case)

markdown

## TC-XXX-001: [Title]

**Priority:** P0 | P1 | P2
**Type:** UI | API | Integration | Regression
**Tags:** [tag1, tag2]
**Traceability:** AC-001 (`requirements/prd.md#...` or `requirements/solution.md#...`)
**Suite:** smoke, regression

### Objective
[One sentence stating what to verify]

### Preconditions
- ...

### Test Data
- ...

### Test Steps
1. ...
   **Expected:** ...
2. ...
   **Expected:** ...

### Post conditions/Cleanup
- ...

DoD Self-Check (V2-DoD)

All P0/P1 test cases are "executable": preconditions and data are not missing
Each step has "expected results" (observable, determinable)
AC coverage relationship is clear (at least can answer "which AC are covered by which test cases")
Test case structure meets the minimum information requirements for subsequent automated generation (ID/type/steps/assertion points)

Output and Automatic Routing After Completion (Must Be Executed)

After

usecase.md

is saved to disk, must complete the following actions (in order, cannot be omitted):

Output ROUTER_SUMMARY (in YAML format, for Router decision making):

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "Soft checkpoint: Test cases have been generated/updated; Router can continue to automatically advance to V3 (spec-test-suites) or V4 (spec-test-execute)"

Execute
using-aisdlc
immediately: Pass the above
```
ROUTER_SUMMARY
```
as routing input to using-aisdlc, the Router will decide the next step and advance automatically (no need to wait for the user to say "continue").
- If the Router determines that automatic continuous running is possible: Continue to execute the next worker skill in the same round of conversation (such as V3, V4, etc.)
- If the Router triggers a hard interrupt: Stop and output the blocking reason, required input, and candidate next steps
Conversation output: Before calling using-aisdlc, you can briefly state "The product of this phase has been saved to disk, calling using-aisdlc to route the next step."

name: spec-test-usecase description: Use when you need to generate or update V2 test cases (verification/usecase.md) for the verification phase in the Spec Pack of sdlc-dev, and must ensure the test case structure is executable, each step has expected results, and AC is traceable.

Spec Test Cases (V2: verification/usecase.md)

Overview

This skill is a verification phase worker skill, only responsible for:

Access control verification (first locate
```
{FEATURE_DIR}
```
, then read necessary inputs)
Generate/update
```
{FEATURE_DIR}/verification/usecase.md
```
Self-check according to V2-DoD (executable + traceable + automation friendly structure)
Output
```
ROUTER_SUMMARY
```
and return to
```
using-aisdlc
```

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (guessing paths is prohibited)

powershell

. ".\skills\spec-context\scripts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

Stop immediately if it fails.

2) Must read project-level Memory (write CONTEXT GAP if missing)

```
.aisdlc/project/memory/product.md
```
```
.aisdlc/project/memory/tech.md
```
```
.aisdlc/project/memory/glossary.md
```

If any is missing: Explicitly write

CONTEXT GAP

usecase.md

(and explain the impact on test case specifications).

3) At least one AC source exists

Must read one of them as the acceptance criteria source:

```
{FEATURE_DIR}/requirements/solution.md
```
or
```
{FEATURE_DIR}/requirements/prd.md
```

If neither exists: Stop and return to

using-aisdlc

4) Test plan is recommended as constraint input

{FEATURE_DIR}/verification/test-plan.md

already exists: Read it to constrain scope/environment/priority specifications; if it does not exist: Write

CONTEXT GAP

usecase.md

and put the gap into risk/blocking items (do not leave it hanging with

TBD

Output (Save to Disk)

```
{FEATURE_DIR}/verification/usecase.md
```

usecase.md

Structure Requirements (Mandatory)

ID Specification

Stable ID:
```
TC-<DOMAIN>-<NNN>
```
(for example
```
TC-AUTH-001
```
)
Do not change the ID randomly after release and collaboration
Self-created ID systems such as
```
UC-001
```
,
```
CASE-1
```
are prohibited

Minimum Template for Single Test Case (Required Fields Must Be Complete)

markdown

## TC-XXX-001: [Title]

**Priority:** P0 | P1 | P2
**Type:** UI | API | Integration | Regression
**Tags:** [tag1, tag2]
**Traceability:** AC-001 (`requirements/solution.md#...` or `requirements/prd.md#...`)
**Suite:** smoke, regression

### Objective
[One sentence stating what to verify]

### Preconditions
- ...

### Test Data
- ...

### Test Steps
1. ...
   **Expected:** ... (observable, determinable)
2. ...
   **Expected:** ...

### Post conditions/Cleanup
- ...

Minimum Standard for "Observable Expectations"

Expectations must point to determinable signals, for example (choose one, the more specific the better):

UI copy/control state/jump path
HTTP status code/response body fields
Whether data records are created/updated (including key fields)
Log keywords/audit events

Undeterminable wording such as "success/normal/meets expectations" is prohibited.

V2-DoD Self-Check

P0/P1 test cases are executable (preconditions and data are not missing)
Each step has observable expected results (can determine pass/fail)
AC coverage relationship is answerable (which AC are covered by which test cases)
Test case IDs are stable, and the structure is available for subsequent automated generation

Anti-patterns (Must Be Avoided)

Anti-pattern	Why it is not allowed	Correct practice
Use `TBD/to be confirmed` to occupy steps or data	Test cases are not executable	Put missing items into risk/blocking items and explain the impact
No expected results for each step	Cannot determine pass/fail	Write observable assertion points for each step
Only write titles that "cover many aspects"	Not executable	Must complete preconditions/data/step/expectations besides the title

Red Flag STOP

Start writing
```
usecase.md
```
without echoing
```
FEATURE_DIR=...
```
Test case ID system deviates from
```
TC-<DOMAIN>-<NNN>
```
Undeterminable wording such as "success/normal/meets expectations" appears in step expectations

Output and Automatic Routing After Completion (Must Be Executed)

After

usecase.md

is saved to disk, must complete the following actions (in order, cannot be omitted):

Output ROUTER_SUMMARY (in YAML format, for Router decision making):

yaml

ROUTER_SUMMARY:
  stage: V2
  artifacts:
    - "{FEATURE_DIR}/verification/usecase.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "Soft checkpoint: Test cases have been generated/updated; Router can continue to automatically advance to V3 (spec-test-suites) or V4 (spec-test-execute)"

Execute
using-aisdlc
immediately: Pass the above
```
ROUTER_SUMMARY
```
as routing input to using-aisdlc, the Router will decide the next step and advance automatically (no need to wait for the user to say "continue").
- If the Router determines that automatic continuous running is possible: Continue to execute the next worker skill in the same round of conversation (such as V3, V4, etc.)
- If the Router triggers a hard interrupt: Stop and output the blocking reason, required input, and candidate next steps
Conversation output: Before calling using-aisdlc, you can briefly state "The product of this phase has been saved to disk, calling using-aisdlc to route the next step."

spec-test-usecase

NPX Install

Tags

SKILL.md Content (Chinese)

Spec Test Cases (V2: Usecase)

Hard Access Control (Must Comply)

Red Flag Checklist (Stop if Any Item Occurs)

The Only Operation Method (PowerShell)

1) Get
`FEATURE_DIR`

2) Target Output Path

Test Case Structure (Mandatory, Automation Friendly)

Minimum Template (Single Test Case)

DoD Self-Check (V2-DoD)

Output and Automatic Routing After Completion (Must Be Executed)

name: spec-test-usecase description: Use when you need to generate or update V2 test cases (verification/usecase.md) for the verification phase in the Spec Pack of sdlc-dev, and must ensure the test case structure is executable, each step has expected results, and AC is traceable.

Spec Test Cases (V2: verification/usecase.md)

Overview

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (guessing paths is prohibited)

2) Must read project-level Memory (write CONTEXT GAP if missing)

3) At least one AC source exists

4) Test plan is recommended as constraint input

Output (Save to Disk)

`usecase.md`
Structure Requirements (Mandatory)

ID Specification

Minimum Template for Single Test Case (Required Fields Must Be Complete)

Minimum Standard for "Observable Expectations"

V2-DoD Self-Check

Anti-patterns (Must Be Avoided)

Red Flag STOP

Output and Automatic Routing After Completion (Must Be Executed)