test-report-review

Test Report Review

Objective

Perform a consistency check on the test report, raw evidence, scope, role reports, and project actions to form traceable AI-assisted recommendations. Review only the provided materials; the Human retains the final decision.

When to Use

• The test report claims pass, releasable, or gate compliance, and the raw execution and defect evidence needs to be verified.
• Untested scope, evidence contradictions, residual risks, or unclosed actions need to be exposed.
• Scheduling or management opinions may conflict with QA, technical, or raw quality facts.

Execution Flow

1. Read prompts/test-report-review.md, and execute according to the complete specification.
2. Build an input list, recording each source's identifier, version, responsible role, and whether it is readable; when no version is provided, write not supplied, and do not guess.
3. Align the report conclusions item by item with execution evidence, defect evidence, tested/untested scope, role reports, and project actions.
4. List contradictions, hidden or unknown scope, residual risks, conditions, and open actions separately, retaining each one's source.
5. Based on blocking items and conditional items, give an AI-assisted recommendation of pass、conditional_pass or reject .
6. Before delivery, check the evidence boundaries, source versions, responsible parties, and the Human's final decision status.

Inviolable Rules

• When both execution evidence and defect evidence are missing, the status must be Not executed or insufficient evidence, and the recommendation must be reject; the report summary, role opinions, or scheduling cannot rewrite it as pass.
• Statistics such as 80/80 or 100% only prove the execution scope to which they explicitly correspond, and must not be extrapolated to untested, omitted, or version-unknown scope.
• PM input only provides scheduling, resources, dependencies, responsibilities, and action status; it must not change execution results, defect severity/status, quality facts, risks, or the Human decision.
• Each conclusion cites its source and version; when a conflict is not resolved with authorization, retain both sides and do not choose the side more favorable to the project on your own.
• The output is always an AI-assisted recommendation, and maintains human_final_decision: pending; it must not claim to have approved, released, or accepted risk.

Recommendation Rules

• reject: There are blocking items, such as no reviewable report, both execution and defect evidence missing, key untested scope hidden, open P0/P1, key conclusions conflicting with raw evidence, or quality facts overridden without authority.
• conditional_pass: There are no blocking items, but there are non-blocking conditions with clear scope, traceable responsibility and closure thresholds, and verifiable closure evidence.
• pass: The report is consistent with the raw evidence, with no blocking items or conditional items; improvement items that do not affect the recommendation may be retained.

Do not vote by number of findings, and do not use positive evidence to offset one key blocking item.

Output Requirements

Output in order:Review status, sources and versions, evidence consistency matrix, tested and untested scope, contradictions, blocking items and conditional items, residual risks, open actions, recommendation basis and limitations, questions pending Human decision. For required sections with no content, explicitly write "None"; do not omit them.

Load as Needed

• Read on every execution prompts/test-report-review.md; it is a complete, independently runnable review specification.
• This Skill does not depend on other Skills, project paths, or database objects. When a role report is missing, treat it as an input gap and do not attempt to read another Skill's private files.

Common Misconceptions

• Treating "all passed" in a report as raw execution evidence.
• Listing only the tested count, without listing approved exclusions, unknown scope, and hidden untested items.
• Treating fixed as verified, or treating a no-defect record as no defects.
• Rewriting failure results, defect severity, or risk because the release date is approaching.
• Giving conditional_pass, but without an owner/unassigned status, closure threshold, and verification evidence.

Pre-delivery Self-check

• The presence and version of execution evidence and defect evidence are clear
• The report conclusions, scope, statistics, and gates have all been checked against the raw evidence
• Contradictions, untested scope, residual risk, and open actions are all visible
• Each condition has an owner or unassigned, closure threshold, and verification evidence
• The PM input does not cover quality facts
• The recommendations comply with the rules, and human_final_decision: pending