spec-test-bug

Original：🇨🇳 Chinese

Translated

Use when you need to create defect reports that can be directly pasted into external defect systems (without saving bug files in the Spec Pack) during the verification phase of the Spec Pack, and write the defect references back to `{FEATURE_DIR}/verification/report-*.md`.

2installs

Sourcezixun-github/aisdlc

Added on2026-03-04

NPX Install

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

SKILL.md Content (Chinese)

View Translation Comparison →

Spec Defect Report (Vx: Bug Report Drafting)

This skill is used to generate structured defect report content (for external systems like Jira/禅道/Linear/GitHub Issue) during the verification phase, and ensure that defect information can be fed back to the

report-*.md

in the Spec Pack (as evidence of delivery blockages and risks).

Important Boundaries:
Prohibited: Do not add
verification/bugs/**
or any bug files/directories within the Spec Pack.
The output of this skill is mainly "conversation output" for pasting into external defect systems; after creating the external defect, write information such as the number/link back to the "Defect List" in
report-*.md
.

Input and Access Control (Mandatory Compliance)

REQUIRED SUB-SKILL: First meet the
spec-context
access control and echo
FEATURE_DIR=...
in the conversation (allow
(reuse)
).

Locate first, then write back: If you need to write defect numbers/links back to
```
report-*.md
```
, you must first obtain
```
FEATURE_DIR
```
through
```
spec-context
```
; stop immediately if it fails, and do not guess the path.

Mandatory project-level memory:

project/memory/product.md

,

project/memory/tech.md

,

project/memory/glossary.md

; write

CONTEXT GAP

if any are missing.

Minimum factual input (to be provided by the user or extracted from context):
- Phenomenon description (actual vs expected)
- Reproduction steps (reproducible by others)
- Environment information (OS/browser/device/environment/version or build)
- Impact assessment (user impact/frequency/business impact/data impact/security impact)
- Evidence (screenshots/screen recordings/logs/network request summaries; can be empty but the reason must be explained)
- Associated use case ID: At least one
```
TC-*
```
  (from
```
verification/usecase.md
```
  )

Output (Conversation Output, No Bug Files Saved)

This skill outputs two parts:

Defect Report Content (Markdown): Generated according to the template, can be directly pasted into external defect systems.
Report Write-back Snippet (Markdown): Used to paste into the "Defect List / Block Items" section of
```
{FEATURE_DIR}/verification/report-{date}-{version}.md
```
, including the following fields:
- External defect number + link + status + severity/priority
- Associated
```
TC-*
```
- Whether delivery is blocked (aligned with the Exit Criteria in
```
test-plan.md
```
  )

Template Source (Mandatory Use):

```
assets/bug_report_templates.md
```

Execution Key Points (Mandatory)

Title must be specific:
```
[Module/Capability] [Error] occurs under [Condition/Operation]
```
(avoid vague phrases like "has bug/not working").
Reproduction steps must be executable: Each step should be specific, avoid "click the button then an error occurs".
Environment must be traceable: At least include OS, browser/device, environment (Dev/Staging/Prod) and version/build.
Sensitive information handling: Logs/screenshots must be desensitized; for security-related issues, avoid providing directly exploitable attack code.
Bind to use cases: Defects must be associated with at least one
```
TC-*
```
, otherwise the
```
report
```
will be untraceable.

DoD Self-Check

Title is specific and searchable
Reproduction steps can be reproduced by a third party
Expected vs actual is clear
Environment information is complete and traceable
Severity / Priority is provided
Associated with
```
TC-*
```
Evidence is provided or the reason for absence is stated
Impact on delivery and whether it is blocked is specified