spec-test-execute

Original：🇨🇳 Chinese

Translated

Use when you need to generate `{FEATURE_DIR}/verification/report-{date}-{version}.md` (test report) during the verification phase of Spec Pack, provide deliverable conclusions that are traceable to test cases and defect references.

2installs

Sourcezixun-github/aisdlc

Added on2026-03-02

NPX Install

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

SKILL.md Content (Chinese)

View Translation Comparison →

Spec Test Execution and Report (V4: Execute + Report)

This skill produces a "conclusive test report" that answers whether AC is met, whether it is deliverable, what the blocking points are, and what the next actions are.

Official Specification:

design/aisdlc_spec_verification.md

Hard Access Control (Mandatory Compliance)

Locate path before read/write: You must run
```
spec-context
```
first to get and echo
```
FEATURE_DIR=...
```
; stop immediately if it fails, do not guess the path.
Mandatory reading of project-level memory:
```
project/memory/product.md
```
,
```
project/memory/tech.md
```
,
```
project/memory/glossary.md
```
; if you cannot read them, you must write
```
CONTEXT GAP
```
.
Input dependencies:
```
verification/test-plan.md
```
and
```
verification/usecase.md
```
must exist; if
```
verification/suites.md
```
exists, include it in coverage statistics.
Defects are not stored in Spec Pack: Do not create new
```
verification/bugs/**
```
; the report only includes a reference list of "defect ID/link/status/severity".
No unauthorized routing: Only output
```
ROUTER_SUMMARY
```
after completion, the next step is decided by
```
using-aisdlc
```
.

Red Flag Checklist (Stop if any item occurs)

Attempting to write a "conclusive report" without
```
test-plan.md
```
/
```
usecase.md
```
Attempting to store defect details in
```
verification/bugs/**
```
(only references to external defect systems are allowed in this phase)
Attempting to write a fixed version number or use
```
TBD
```
when the version is unknown (you must use
```
unknown
```
and explicitly mark
```
CONTEXT GAP
```
)

Only Valid Procedure (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) Naming Rules (Mandatory)

```
date
```
:
```
YYYY-MM-DD
```
```
version
```
: Traceable identifier for build/release (version number, build id, git sha)

If the version is unknown: use

report-{date}-unknown.md

, and write

CONTEXT GAP: version/build unknown

in the report.

3) Target Output Path (Example)

powershell

$date = "2026-03-02"
$version = "unknown"
$out = Join-Path $FEATURE_DIR ("verification/report-{0}-{1}.md" -f $date, $version)
Write-Host "OUTPUT=$out"

Minimum Report Structure (Recommendation)

Write to

{FEATURE_DIR}/verification/report-{date}-{version}.md

, including at least:

Test Summary
- Conclusion: Pass / Fail / Conditional Pass
- Version/Build/Environment (must write
```
CONTEXT GAP
```
  if unknown)
Coverage Statistics
- By suite/priority: Total, Executed, Passed, Failed, Blocked, Not Run
Key Failures and Blockers
- Must be traceable to test case ID (TC-...)
Defect List (References only)
- Defect system/Issue ID + link + status + severity
Remaining Risks and Recommendations
- Next actions must be executable (rework/retest/gray release/add monitoring/rollback suggestions)

Traceability Links

requirements/*

verification/test-plan.md

verification/usecase.md

, (optional)

verification/suites.md

DoD Self-Check (V4-DoD)

The report has a clear conclusion (not "test completed")
All failures/blockers can be linked to
```
TC-*
```
and external defect IDs (if any)
Risks and recommendations are executable (next actions are clear)

Output Convention (Return to Router)

text

ROUTER_SUMMARY
- feature_dir: <FEATURE_DIR>
- outputs:
  - verification/report-<date>-<version>.md
- context_gaps:
  - <CONTEXT GAP...> (if any)
- dod:
  - pass: <yes/no> (and why)
  - next_risks: <short list>

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output

report-{date}-{version}.md

(as the carrier of execution evidence and conclusions).

Spec Test Execution (V4: Perform Validation and Generate Report)

Overview

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

Access control verification (first locate
```
{FEATURE_DIR}
```
, then read necessary inputs)
Execution validation (can be records of manual execution/automated execution; no framework binding)

Produce execution output:

{FEATURE_DIR}/verification/report-{date}-{version}.md

Self-check according to V4-DoD (conclusive + traceable)
Output
```
ROUTER_SUMMARY
```
and return to
```
using-aisdlc
```

This skill does not decide what to do next (routed by

using-aisdlc

Report Naming Rules (Mandatory)

File name:
```
report-{date}-{version}.md
```
```
date
```
:
```
YYYY-MM-DD
```
```
version
```
: Build/release version number or traceable identifier (e.g.
```
v1.7.3
```
,
```
build-20260302.1
```
,
```
sha-abc1234
```
)

version

is not available: you can still generate the report, but you must:

Use
```
report-{date}-unknown.md
```
as the file name
Write
```
CONTEXT GAP: version/build unknown
```
in the report, and reduce the confidence level in the conclusion (usually conditional pass/fail, depending on the release criteria and blockers)

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (do not guess the path)

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 failed.

2) Mandatory reading of 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

in the report, and explain how it affects the credibility of the conclusion.

3) Must read verification inputs

Must read before execution:

```
{FEATURE_DIR}/verification/test-plan.md
```
```
{FEATURE_DIR}/verification/usecase.md
```
```
{FEATURE_DIR}/verification/suites.md
```
(if exists)

If missing: stop and return to

using-aisdlc

(since scope/specification/coverage cannot be proven).

Execution Record Requirements (Minimum)

Use the test case ID (
```
TC-...
```
) in
```
usecase.md
```
as the minimum statistical unit
Each test case must have a result: Pass / Fail / Blocked / Not Run
Fail/Blocked must provide:
- Corresponding
```
TC-...
```
- External defect ID/link (or clearly state the blocking reason and next action for "defect not yet submitted")
Do not add
```
verification/bugs/**
```
in the Spec Pack

Output (Write to Disk)

{FEATURE_DIR}/verification/report-{date}-{version}.md

Minimum Report Structure (Must Include)

Test Summary
- Conclusion: Pass / Fail / Conditional Pass (choose one of three)
- Version/Build/Environment
- Execution date (consistent with the date in the file name)
Coverage Statistics
- By priority and (if exists) suite: Total, Executed, Passed, Failed, Blocked, Not Run
Test Case Result List
- ```
TC-...
```
  → Pass/Fail/Blocked/Not Run
Key Failures and Blockers
- Each item must be traceable to TC ID
Defect List (only reference external systems)
- Defect ID/link/status/severity
- Must be associated with the corresponding TC ID
Remaining Risks and Recommendations (executable next actions)
Traceability Links (key entries for requirements/design/implementation)
CONTEXT GAP (if any)

V4-DoD Self-Check

The report gives a clear conclusion (not "test completed")
All failures/blockers can be linked to TC ID and external defect ID/link
Statistical caliber is explainable (why not executed/why blocked)
Risks and recommendations are executable (next actions are clear)

Red Flag STOP

Start execution/write report to disk without echoing
```
FEATURE_DIR=...
```
Conclusion is "Pass" but there are unexecuted/blocked items without explanation
Fail/Blocked is not associated with TC ID or external defect reference

Output Convention (For Router)

text

ROUTER_SUMMARY
- FEATURE_DIR=...
- report_written: verification/report-{date}-{version}.md
- execution_summary:
  - totals: { planned: ?, executed: ?, pass: ?, fail: ?, blocked: ?, not_run: ? }
  - blockers: [ ... ]
- context_gaps: [...]
- open_risks: [...]
- blocked_by: [...]
- router_hints: ["回到 using-aisdlc 继续路由"]

Spec Test Execution and Report (V4: Execute + Report)

This skill produces a "conclusive test report" that answers whether AC is met, whether it is deliverable, what the blocking points are, and what the next actions are.

Official Specification:

design/aisdlc_spec_verification.md

Hard Access Control (Mandatory Compliance)

Locate path before read/write: You must run
```
spec-context
```
first to get and echo
```
FEATURE_DIR=...
```
; stop immediately if it fails, do not guess the path.
Mandatory reading of project-level memory:
```
project/memory/product.md
```
,
```
project/memory/tech.md
```
,
```
project/memory/glossary.md
```
; if you cannot read them, you must write
```
CONTEXT GAP
```
.
Input dependencies:
```
verification/test-plan.md
```
and
```
verification/usecase.md
```
must exist; if
```
verification/suites.md
```
exists, include it in coverage statistics.
Defects are not stored in Spec Pack: Do not create new
```
verification/bugs/**
```
; the report only includes a reference list of "defect ID/link/status/severity".
No unauthorized routing: Only output
```
ROUTER_SUMMARY
```
after completion, the next step is decided by
```
using-aisdlc
```
.

Red Flag Checklist (Stop if any item occurs)

Attempting to write a "conclusive report" without
```
test-plan.md
```
/
```
usecase.md
```
Attempting to store defect details in
```
verification/bugs/**
```
(only references to external defect systems are allowed in this phase)
Attempting to write a fixed version number or use
```
TBD
```
when the version is unknown (you must use
```
unknown
```
and explicitly mark
```
CONTEXT GAP
```
)

Only Valid Procedure (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) Naming Rules (Mandatory)

```
date
```
:
```
YYYY-MM-DD
```
```
version
```
: Traceable identifier for build/release (version number, build id, git sha)

If the version is unknown: use

report-{date}-unknown.md

, and write

CONTEXT GAP: version/build unknown

in the report.

3) Target Output Path (Example)

powershell

$date = "2026-03-02"
$version = "unknown"
$out = Join-Path $FEATURE_DIR ("verification/report-{0}-{1}.md" -f $date, $version)
Write-Host "OUTPUT=$out"

Minimum Report Structure (Recommendation)

Write to

{FEATURE_DIR}/verification/report-{date}-{version}.md

, including at least:

Test Summary
- Conclusion: Pass / Fail / Conditional Pass
- Version/Build/Environment (must write
```
CONTEXT GAP
```
  if unknown)
Coverage Statistics
- By suite/priority: Total, Executed, Passed, Failed, Blocked, Not Run
Key Failures and Blockers
- Must be traceable to test case ID (TC-...)
Defect List (References only)
- Defect system/Issue ID + link + status + severity
Remaining Risks and Recommendations
- Next actions must be executable (rework/retest/gray release/add monitoring/rollback suggestions)

Traceability Links

requirements/*

verification/test-plan.md

verification/usecase.md

, (optional)

verification/suites.md

DoD Self-Check (V4-DoD)

The report has a clear conclusion (not "test completed")
All failures/blockers can be linked to
```
TC-*
```
and external defect IDs (if any)
Risks and recommendations are executable (next actions are clear)

Output Convention (Return to Router)

text

ROUTER_SUMMARY
- feature_dir: <FEATURE_DIR>
- outputs:
  - verification/report-<date>-<version>.md
- context_gaps:
  - <CONTEXT GAP...> (if any)
- dod:
  - pass: <yes/no> (and why)
  - next_risks: <short list>

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output

report-{date}-{version}.md

(as the carrier of execution evidence and conclusions).

Spec Test Execution (V4: Perform Validation and Generate Report)

Overview

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

Access control verification (first locate
```
{FEATURE_DIR}
```
, then read necessary inputs)
Execution validation (can be records of manual execution/automated execution; no framework binding)

Produce execution output:

{FEATURE_DIR}/verification/report-{date}-{version}.md

Self-check according to V4-DoD (conclusive + traceable)
Output
```
ROUTER_SUMMARY
```
and return to
```
using-aisdlc
```

This skill does not decide what to do next (routed by

using-aisdlc

Report Naming Rules (Mandatory)

File name:
```
report-{date}-{version}.md
```
```
date
```
:
```
YYYY-MM-DD
```
```
version
```
: Build/release version number or traceable identifier (e.g.
```
v1.7.3
```
,
```
build-20260302.1
```
,
```
sha-abc1234
```
)

version

is not available: you can still generate the report, but you must:

Use
```
report-{date}-unknown.md
```
as the file name
Write
```
CONTEXT GAP: version/build unknown
```
in the report, and reduce the confidence level in the conclusion (usually conditional pass/fail, depending on the release criteria and blockers)

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (do not guess the path)

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 failed.

2) Mandatory reading of 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

in the report, and explain how it affects the credibility of the conclusion.

3) Must read verification inputs

Must read before execution:

```
{FEATURE_DIR}/verification/test-plan.md
```
```
{FEATURE_DIR}/verification/usecase.md
```
```
{FEATURE_DIR}/verification/suites.md
```
(if exists)

If missing: stop and return to

using-aisdlc

(since scope/specification/coverage cannot be proven).

Execution Record Requirements (Minimum)

Use the test case ID (
```
TC-...
```
) in
```
usecase.md
```
as the minimum statistical unit
Each test case must have a result: Pass / Fail / Blocked / Not Run
Fail/Blocked must provide:
- Corresponding
```
TC-...
```
- External defect ID/link (or clearly state the blocking reason and next action for "defect not yet submitted")
Do not add
```
verification/bugs/**
```
in the Spec Pack

Output (Write to Disk)

{FEATURE_DIR}/verification/report-{date}-{version}.md

Minimum Report Structure (Must Include)

Test Summary
- Conclusion: Pass / Fail / Conditional Pass (choose one of three)
- Version/Build/Environment
- Execution date (consistent with the date in the file name)
Coverage Statistics
- By priority and (if exists) suite: Total, Executed, Passed, Failed, Blocked, Not Run
Test Case Result List
- ```
TC-...
```
  → Pass/Fail/Blocked/Not Run
Key Failures and Blockers
- Each item must be traceable to TC ID
Defect List (only reference external systems)
- Defect ID/link/status/severity
- Must be associated with the corresponding TC ID
Remaining Risks and Recommendations (executable next actions)
Traceability Links (key entries for requirements/design/implementation)
CONTEXT GAP (if any)

V4-DoD Self-Check

The report gives a clear conclusion (not "test completed")
All failures/blockers can be linked to TC ID and external defect ID/link
Statistical caliber is explainable (why not executed/why blocked)
Risks and recommendations are executable (next actions are clear)

Red Flag STOP

Start execution/write report to disk without echoing
```
FEATURE_DIR=...
```
Conclusion is "Pass" but there are unexecuted/blocked items without explanation
Fail/Blocked is not associated with TC ID or external defect reference

Output Convention (For Router)

text

ROUTER_SUMMARY
- FEATURE_DIR=...
- report_written: verification/report-{date}-{version}.md
- execution_summary:
  - totals: { planned: ?, executed: ?, pass: ?, fail: ?, blocked: ?, not_run: ? }
  - blockers: [ ... ]
- context_gaps: [...]
- open_risks: [...]
- blocked_by: [...]
- router_hints: ["回到 using-aisdlc 继续路由"]

spec-test-execute

NPX Install

Tags

SKILL.md Content (Chinese)

Spec Test Execution and Report (V4: Execute + Report)

Hard Access Control (Mandatory Compliance)

Red Flag Checklist (Stop if any item occurs)

Only Valid Procedure (PowerShell)

1) Get FEATURE_DIR

2) Naming Rules (Mandatory)

3) Target Output Path (Example)

Minimum Report Structure (Recommendation)

DoD Self-Check (V4-DoD)

Output Convention (Return to Router)

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output report-{date}-{version}.md (as the carrier of execution evidence and conclusions).

Spec Test Execution (V4: Perform Validation and Generate Report)

Overview

Report Naming Rules (Mandatory)

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (do not guess the path)

2) Mandatory reading of project-level Memory (write CONTEXT GAP if missing)

3) Must read verification inputs

Execution Record Requirements (Minimum)

Output (Write to Disk)

Minimum Report Structure (Must Include)

V4-DoD Self-Check

Red Flag STOP

Output Convention (For Router)

spec-test-execute

NPX Install

Tags

SKILL.md Content (Chinese)

Spec Test Execution and Report (V4: Execute + Report)

Hard Access Control (Mandatory Compliance)

Red Flag Checklist (Stop if any item occurs)

Only Valid Procedure (PowerShell)

1) Get FEATURE_DIR

2) Naming Rules (Mandatory)

3) Target Output Path (Example)

Minimum Report Structure (Recommendation)

DoD Self-Check (V4-DoD)

Output Convention (Return to Router)

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output report-{date}-{version}.md (as the carrier of execution evidence and conclusions).

Spec Test Execution (V4: Perform Validation and Generate Report)

Overview

Report Naming Rules (Mandatory)

Hard Access Control (Cannot Be Bypassed)

1) Locate FEATURE_DIR first (do not guess the path)

2) Mandatory reading of project-level Memory (write CONTEXT GAP if missing)

3) Must read verification inputs

Execution Record Requirements (Minimum)

Output (Write to Disk)

Minimum Report Structure (Must Include)

V4-DoD Self-Check

Red Flag STOP

Output Convention (For Router)

1) Get
`FEATURE_DIR`

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output
`report-{date}-{version}.md`
(as the carrier of execution evidence and conclusions).

1) Get
`FEATURE_DIR`

name: spec-test-execute description: Use when you need to perform verification phase validation (V4) in the Spec Pack of sdlc-dev, record execution results and produce the report output
`report-{date}-{version}.md`
(as the carrier of execution evidence and conclusions).