| name | test-report-review |
| description | Use this skill when a test report needs an evidence-consistency review before Human approval; triggers include test report review, quality report audit, test evidence review, 测试报告评审 and 测试结论复核. |
Test Report Review
Goal
Check a test report against source evidence, scope, role reports, and project actions, then produce a traceable AI-assisted recommendation. Review only supplied material; a Human retains the final decision.
When to use
- A report claims tests passed, gates are met, or release is ready and needs source-evidence review.
- Untested scope, evidence contradictions, residual risk, or open actions need to be visible.
- Schedule or management input may conflict with QA, technical, or source quality facts.
Workflow
- Read prompts/test-report-review.md and follow the complete specification.
- Inventory every source with identifier, version, accountable role, and availability; write
not supplied for an absent version instead of guessing.
- Check each report claim against execution evidence, defect evidence, tested/untested scope, role reports, and project actions.
- Separately list contradictions, hidden or unknown scope, residual risks, conditions, and open actions with their sources.
- Apply blocker and condition rules to issue an AI-assisted
pass, conditional_pass, or reject recommendation.
- Before delivery, check evidence boundaries, source versions, ownership, and pending Human authority.
Invariants
- When execution evidence and defect evidence are both absent, the state is not executed or insufficient evidence and the recommendation is
reject. A report summary, role opinion, or schedule cannot convert it to pass.
- Counts such as 80/80 or 100% prove only their explicitly evidenced execution scope; never extrapolate them to untested, omitted, or version-unknown scope.
- PM input supplies schedule, resources, dependencies, ownership, and action status only. It cannot change execution results, defect severity/status, quality facts, risk, or the Human decision.
- Cite a source and version for every conclusion. Preserve conflicting sources until an authorized resolution is supplied; never select the more convenient source.
- Always label the output an AI-assisted recommendation and keep
human_final_decision: pending. Never claim approval, release authorization, or risk acceptance occurred.
Recommendation rules
reject: a blocker exists, such as no reviewable report; both execution and defect evidence absent; hidden critical untested scope; an open P0/P1; a critical source contradiction; or unauthorized quality-fact override.conditional_pass: no blocker exists, but a bounded non-blocking condition has traceable ownership, an observable closure gate, and verifiable closure evidence.pass: report and source evidence align with no blocker or condition; optional improvements may remain.
Do not vote by finding count. Positive evidence never cancels one critical blocker.
Output contract
Output in this order: Review Status, Sources and Versions, Evidence Consistency Matrix, Tested and Untested Scope, Contradictions, Blockers and Conditions, Residual Risks, Open Actions, Recommendation Basis and Limitations, Human Decision Questions. Keep every required section and explicitly state none when empty.
Progressive loading
- Read
prompts/test-report-review.md on every run; it is the complete standalone review specification.
- This Skill has no dependency on another Skill, project path, or database object. Treat missing role reports as input gaps; do not read another Skill's private files.
Common mistakes
- Treating a report's "all passed" sentence as raw execution evidence.
- Listing tested counts but omitting approved exclusions, unknown scope, or hidden untested items.
- Treating
fixed as verified, or no defect record as proof of no defects.
- Rewriting a failure, defect severity, or risk because a release date is close.
- Issuing
conditional_pass without an owner or unassigned state, closure gate, and verification evidence.
Pre-delivery check
