Synced: 2026-09-03
Test Reporting
Need help with test reporting in a real project context.
When to Use
- Need help with test reporting in a real project context.
- Need an output that can be used directly for execution, review, or follow-up.
Workflow
- Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
- Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
- If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
- Default to Markdown; switch formats only when the user asks.
Core Constraints
- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts from current assumptions.
- Keep confirmed facts, inference, missing evidence, residual risk, and recommendations in identifiable sections.
- Do not invent endpoints, fields, environments, or root causes the user did not provide.
- Keep output executable: concrete scenarios, clear priority, clear next steps.
- When both execution and defect evidence are absent, the only overall quality state is
not executed or insufficient evidence; never report pass or release readiness.
Progressive Disclosure
- Before producing output, read and follow
prompts/test-reporting.md(minimum coverage, output structure, quality bar). - When Excel/CSV/JSON/Word is requested: read
output-formats.mdand honor the format. - When a ready-made template fits: use matching files under
output-templates/. - For format conversion or helper checks: prefer existing
scripts/over reinventing. - For evaluating/regressing this skill: use
evals/with skill-up.
Pre-delivery Checklist
- Followed the main prompt's output structure
- Minimum coverage focus: scope tested, scope not tested, overall status, critical defects or blockers, risk summary, coverage confidence, environment or data issues, recommended release position, ... (details in main prompt)
- Covered the minimum checklist, or explained omissions
- High-risk items have explicit priority
- Did not invent details the user did not provide
- Assumptions and gaps are marked
- Evidence levels are separated; plans, environment readiness, and role opinions are not treated as pass evidence
- Missing execution and defect evidence did not become a pass, zero-defect, or release-ready conclusion
Common Pitfalls
- Do not pretend completeness when scope/context is missing.
- Do not treat every item as equally important.
- Do not skip assumptions and information gaps.
- Do not turn a planned case count into execution, or an absent defect list into zero defects.
- Do not dump generic theory unrelated to the current toolchain.
---
name: test-reporting
description: Use this skill when you need to generate test reports with summary, metrics, defect analysis, and risk assessment; triggers include test reporting and QA status report.
---
# Test Reporting
**Chinese version:** See the corresponding Chinese skill.
## When to Use
- Need help with test reporting in a real project context.
- Need an output that can be used directly for execution, review, or follow-up.
## Workflow
1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
4. Default to Markdown; switch formats only when the user asks.
## Core Constraints
- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts from current assumptions.
- Keep confirmed facts, inference, missing evidence, residual risk, and recommendations in identifiable sections.
- Do not invent endpoints, fields, environments, or root causes the user did not provide.
- Keep output executable: concrete scenarios, clear priority, clear next steps.
- When both execution and defect evidence are absent, the only overall quality state is `not executed or insufficient evidence`; never report pass or release readiness.
## Progressive Disclosure
- Before producing output, read and follow `prompts/test-reporting.md` (minimum coverage, output structure, quality bar).
- When Excel/CSV/JSON/Word is requested: read `output-formats.md` and honor the format.
- When a ready-made template fits: use matching files under `output-templates/`.
- For format conversion or helper checks: prefer existing `scripts/` over reinventing.
- For evaluating/regressing this skill: use `evals/` with skill-up.
## Pre-delivery Checklist
- [ ] Followed the main prompt's output structure
- [ ] Minimum coverage focus: scope tested, scope not tested, overall status, critical defects or blockers, risk summary, coverage confidence, environment or data issues, recommended release position, ... (details in main prompt)
- [ ] Covered the minimum checklist, or explained omissions
- [ ] High-risk items have explicit priority
- [ ] Did not invent details the user did not provide
- [ ] Assumptions and gaps are marked
- [ ] Evidence levels are separated; plans, environment readiness, and role opinions are not treated as pass evidence
- [ ] Missing execution and defect evidence did not become a pass, zero-defect, or release-ready conclusion
## Common Pitfalls
- Do not pretend completeness when scope/context is missing.
- Do not treat every item as equally important.
- Do not skip assumptions and information gaps.
- Do not turn a planned case count into execution, or an absent defect list into zero defects.
- Do not dump generic theory unrelated to the current toolchain. Install & call
Platform
AI Tool
npm install (recommended)
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-reporting -g -a codex -y Quick install (one line)
… Full script
… Call example
@skill test-reporting
Using the current project context, produce an actionable result following this skill.