test-reporting

Test Report (Chinese Version)

English version: See the corresponding English skill.

When to Use

You need to handle test reporting-related tasks in a real project.
You need a result that can be directly used for execution, review, or follow-up.

Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
Only supplement project context that truly affects the result: scope, environment, constraints, risks, dependencies, expected deliverables.
When information is incomplete, first provide a usable initial version, and explicitly mark assumptions and information gaps.
Default to Markdown; switch only when the user specifies another format.

Prioritize by risk/business impact; do not spread effort evenly.
Write "confirmed facts" and "current assumptions" separately.
Divide confirmed facts, inferences, missing evidence, residual risks, and recommendations into distinguishable, independent sections.
Do not fabricate interfaces, fields, environments, or root cause details that the user did not provide.
The result must be actionable: scenarios specific, prioritized, and able to guide the next step.
When both execution evidence and defect evidence are missing, the overall quality status can only be not executed or insufficient evidence(not executed or insufficient evidence); it cannot report pass or release readiness.

Before producing output, you must read and follow prompts/test-reporting.md(minimum coverage checklist, output structure, quality requirements).
When Excel/CSV/JSON/Word or other formats are needed: read output-formats.md, and output according to the user's format requirements.
When a ready-made template needs to be applied: read the matching template in output-templates/ ; do not invent a conflicting structure.
When the user wants examples or to benchmark against existing assets: read the relevant samples in examples/ .
When in-depth materials such as framework specifications, troubleshooting, or report schema are needed: read only the files in references/ that are relevant to the current problem; do not read through the entire directory.
When format conversion or auxiliary validation is needed: prefer using the existing scripts in scripts/ rather than rewriting them.
When evaluating/regressing this skill: use evals/, and validate and run with skill-up.
When the user only wants the shortest onboarding path: read quick-start.md。

The output structure of the main prompt has been followed
Minimum coverage concerns: tested scope, untested scope, overall status, key defects or blockers, risk summary, coverage confidence, environment or data issues, release recommendation... (details are subject to the main prompt)
The minimum checklist has been covered, or it is indicated why it was omitted
High-risk items have clear priorities
No details that the user did not provide have been fabricated
Assumptions and information gaps have been marked
Evidence levels have been separated; plans, environment readiness, or role opinions have not been treated as execution pass evidence
When execution and defect evidence are missing, no pass, zero-defect, or releasable conclusion has been generated

When both scope and context are unclear, do not pretend it is already complete and usable.
Do not write all items as equally important.
Do not skip assumptions and information gaps.
Do not write planned execution counts as actual execution counts, and do not write a missing defect list as zero defects.
Do not output large sections of vague theory unrelated to the current toolchain.