product-quality-perspective

Product Quality Perspective (Chinese Version)

English Version: See the corresponding English skill.

When to Use

• When a quality stage needs to be reviewed from a product perspective covering user value, business rules, scope, acceptance, and release risk.
• When product, engineering, and QA need to advance quality decisions based on the same facts, gaps, and action items.

Inputs

• stage(required):requirements-analysis、test-strategy、test-strategy-review、code-review、test-case-writing、test-case-review、test-reporting or test-report-review。
• Project materials: requirements, PR/Diff, test assets, reports, or other provided evidence.
• Optional stage context: target users, release goals, scope, dependencies, constraints, known risks.

Execution Flow

1. Validate stage. If it is missing or not in the supported list, return "Not Applicable", explain the supported stages, and request a valid stage; do not generate filler findings.
2. Load and follow only the one Prompt in the table below that corresponds to this stage ; do not read across or merge multiple stage Prompts.
3. Based on the provided materials, first determine whether this stage applies. When materials are insufficient or the stage does not apply, explain the reason, existing facts, gaps, and materials that need to be supplemented; do not generate fabricated findings.
4. Generate a standalone product quality report, and clearly separate facts, evidence, inferences, and unverified items.

stage	Prompt to load only
requirements-analysis	prompts/requirements-analysis.md
test-strategy	prompts/test-strategy.md
test-strategy-review	prompts/test-strategy-review.md
code-review	prompts/code-review.md
test-case-writing	prompts/test-case-writing.md
test-case-review	prompts/test-case-review.md
test-reporting	prompts/test-reporting.md
test-report-review	prompts/test-report-review.md

Product Responsibilities and Boundaries

• Focus on user value, business rules, scope, acceptance criteria, understandability, consistency, decision risk, and follow-up actions.
• Use project materials as evidence; when there are no materials, clearly state "unknown" or "to be confirmed"; do not fabricate rules, metrics, test results, defects, or code behavior.
• Do not replace engineering code review, test design/execution, security assessment, or release approval; without corresponding evidence, do not judge code correctness, and do not claim that tests have passed or that release is feasible.

Report Contract

Unless returning "Not Applicable", every report includes: summary, facts, evidence, findings, risks, information gaps, questions to be confirmed, actions, and confidence level. Findings, risks, and actions should be ordered by impact; conclusions must indicate their evidence basis.

Pre-delivery Self-check

• stage has been validated, and only one matching Prompt was loaded
• applicability was determined first; when not applicable, no filler findings were produced
• the report contains the complete contract fields and distinguishes facts, evidence, inferences, and gaps
• no business rules, code correctness, test passes, or release conclusions were fabricated
• action items can be advanced by clear roles, and the confidence level reflects evidence completeness

Load on Demand

• Only after stage is valid, read the uniquely corresponding prompts/ file in the table.
• When evaluation or regression is needed, use evals/ and run skill-up validation; do not treat eval cases as project facts.

Common Pitfalls

• Do not write the product quality perspective as an evidence-free code review or test conclusion.
• Do not mistakenly write "requirements satisfied" as "code correct" or "tests passed".
• Do not use generic checklists to cover up key gaps when materials are incomplete.

Report Source

The report header retains the selected stage, stable source_id , and provided version. When the source ID is missing, declare a temporary local locator; when the version is missing, write unknown, and do not fabricate. Each finding contains a stable finding_id, source/evidence locator, and status. Each action links back to a finding and states the evidence required to close it; owner, date, and action status are filled in only if provided, otherwise unknown. These are independent report fields and do not constitute a dependency on other Skills.