SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsspec-test-bug

spec-test-bug

Testing & quality

View repository

Updated 10-16 08:49

About this skill

Spec Defect Report (Vx: Bug Report Drafting)

This skill is used during the verification phase to generate a structured defect report body(for external systems such as Jira/ZenTao/Linear/GitHub Issue), and to ensure the defect information can flow back to the Spec Pack's report-*.md(as delivery-blocking and risk evidence).

Important boundary:

  • Forbiddento add within the Spec Pack verification/bugs/** or any bug file/directory.
  • The output of this skill is mainly "conversation output", used for pasting into an external defect system; after the external defect is created, information such as the ID/link needs to be written back to report-*.md the "defect list".

Inputs and gates (must be followed)

REQUIRED SUB-SKILL: currently executing spec-context to obtain context, and echo in the conversation FEATURE_DIR=...(allowed (reuse)）。

  • locate first, then write back: if the defect ID/link needs to be written back to report-*.md, you must first obtain spec-context via FEATURE_DIR; stop on failure, guessing paths is forbidden.
  • Required reading of project-level memory：project/memory/product.md、project/memory/tech.md、project/memory/glossary.md; if missing, you must write CONTEXT GAP。
  • Minimum factual inputs(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; may be empty but the reason must be stated)
    • Related case ID: at least 1 TC-*(from verification/usecase.md）

Output (conversation output, no bug file written to disk)

This skill outputs two parts:

  1. Defect report body (Markdown): generated according to the template, can be pasted directly into an external defect system.
  2. Report write-back snippet (Markdown): used for pasting into {FEATURE_DIR}/verification/report-{date}-{version}.md the "defect list / blocking items" section, with fields including:
    • External defect ID + link + status + severity/priority
    • Related TC-*
    • whether it blocks delivery (aligned with test-plan.md the Exit Criteria)

Template source (mandatory):

  • assets/bug_report_templates.md

Execution points (mandatory)

  • The title must be specific：[模块/能力] 在 [条件/操作] 下出现 [错误](avoid "there is a bug/it doesn't work").
  • Reproduction steps must be executable: each step should be specific; avoid "click the button then an error occurs".
  • The environment must be traceable: at minimum include OS, browser/device, environment (Dev/Staging/Prod) and version/build.
  • Sensitive information handling: logs/screenshots must be redacted; for security issues, avoid providing directly exploitable attack code.
  • Bind to cases: a defect must be associated with at least one TC-*, otherwise it will cause report to 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 has been provided
  • Associated TC-*
  • Evidence has been provided or the reason for its absence has been stated
  • The impact on delivery and whether it is blocking have been provided