Product Quality Perspective - QA Skill Library

Why this Skill

It turns this Skill's method into a quality input that can be executed, reviewed, and reused.

A quality stage needs a product perspective on user value, business rules, scope, acceptance, and release risk.
Do not turn a product-quality perspective into unsupported code-review or test-pass conclusions.
Do not equate “the requirement is met” with “the code is correct” or “tests have passed.”

When to use

Use this Skill

A quality stage needs a product perspective on user value, business rules, scope, acceptance, and release risk.
Product, engineering, and QA need to move a quality decision forward from the same facts, gaps, and actions.

Common pitfalls

Do not turn a product-quality perspective into unsupported code-review or test-pass conclusions.
Do not equate “the requirement is met” with “the code is correct” or “tests have passed.”
Do not hide critical information gaps behind a generic checklist.

Input

Minimum Input

Validate `stage`. If it is missing or unsupported, return **Not applicable**, name the supported stages, and request a valid `stage`; do not generate filler findings.

Recommended Input

Only after validating stage, read the one corresponding file in prompts/.
For evaluation or regression, use evals/ and skill-up validation; do not treat eval cases as project evidence.

Optional Context

Relevant code or configuration
Historical results
Logs and metrics

Output

The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.

Judge the output value before installing

01The stage is valid and exactly one matching prompt was loaded
02Applicability was assessed first; a non-applicable result contains no filler findings
03The report has every contract field and separates facts, evidence, inferences, and gaps
04No business rules, code correctness, passed tests, or release conclusion was invented

View full output structure

05Actions have an accountable role and confidence reflects evidence completeness

How It Works

01Validate stage. If it is missing or unsupported, return Not applicable, name the supported stages, and request a valid stage; do not generate filler findings.
02Load and follow exactly one prompt from the table for the valid stage; never combine prompts from multiple stages.
03Use the supplied materials to decide whether the stage is applicable. If materials are insufficient or the stage is not applicable, explain why, list known facts, gaps, and needed material, and do not invent findings.
04Produce a standalone product-quality report that distinguishes facts, evidence, inferences, and unverified items.

Install & Quick Start

Install command / SHELL

npx skills add \
  https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/product-quality-perspective
  -g

product-quality-perspective.prompt

@skill product-quality-perspective

Using the current project context, produce an actionable result following this Skill.

Additional context:
[Paste project context or requirement]

---
name: product-quality-perspective
description: Use this skill when product-quality responsibility is needed across requirements, strategy, review, test-case, or reporting stages; triggers include product quality perspective, product quality review..
---

# Product Quality Perspective (English)

**Chinese version：** See the corresponding Chinese skill.

## When to Use

- A quality stage needs a product perspective on user value, business rules, scope, acceptance, and release risk.
- Product, engineering, and QA need to move a quality decision forward from the same facts, gaps, and actions.

## 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: supplied requirements, PR/diff, test assets, reports, or other evidence.
- Optional stage context: target users, release goal, scope, dependencies, constraints, and known risks.

## Workflow

1. Validate `stage`. If it is missing or unsupported, return **Not applicable**, name the supported stages, and request a valid `stage`; do not generate filler findings.
2. Load and follow exactly one prompt from the table for the valid `stage`; never combine prompts from multiple stages.
3. Use the supplied materials to decide whether the stage is applicable. If materials are insufficient or the stage is not applicable, explain why, list known facts, gaps, and needed material, and do not invent findings.
4. Produce a standalone product-quality report that distinguishes facts, evidence, inferences, and unverified items.

| `stage` | Only prompt to load |
| --- | --- |
| `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, clarity, consistency, decision risk, and next actions.
- Use project materials as evidence. When evidence is absent, say unknown or needs confirmation; never invent rules, metrics, test results, defects, or code behavior.
- Do not replace engineering code review, test design/execution, security assessment, or release approval. Without their evidence, do not assess code correctness, claim tests have passed, or approve a release.

## Report Contract

Unless the result is Not applicable, every report includes: Summary, Facts, Evidence, Findings, Risks, Information gaps, Questions, Actions, and Confidence. Prioritize findings, risks, and actions by impact, and state each conclusion's evidence basis.

## Pre-delivery Checklist

- [ ] The `stage` is valid and exactly one matching prompt was loaded
- [ ] Applicability was assessed first; a non-applicable result contains no filler findings
- [ ] The report has every contract field and separates facts, evidence, inferences, and gaps
- [ ] No business rules, code correctness, passed tests, or release conclusion was invented
- [ ] Actions have an accountable role and confidence reflects evidence completeness

## Progressive Disclosure

- Only after validating `stage`, read the one corresponding file in `prompts/`.
- For evaluation or regression, use `evals/` and skill-up validation; do not treat eval cases as project evidence.

## Common Pitfalls

- Do not turn a product-quality perspective into unsupported code-review or test-pass conclusions.
- Do not equate “the requirement is met” with “the code is correct” or “tests have passed.”
- Do not hide critical information gaps behind a generic checklist.