About qa-quality-perspective
qa-quality-perspective is a skill for evaluating testability, coverage, defects, and quality risk at QA stages. It distinguishes supplied evidence from inference and avoids claiming that tests ran or passed without execution records.
Key features
- 01Eight supported quality stages
- 02Stage-specific prompt selection
- 03Testability and risk assessment
- 04Evidence and inference separation
- 05Qualitative risk anchors
Use cases
- 01Identifying gaps in requirements testability
- 02Reviewing risk-based test coverage
- 03Reporting untested scope and quality risks
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ naodeng/ awesome-qa-skills --skill qa-quality-perspectiveAfter installing, type/qa-quality-perspectivein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
agents/openai.yamlevals/eval.yamlevals/cases/basic-code-review.yamlbasic-requirements-analysis.yamlbasic-test-case-review.yamlbasic-test-case-writing.yamlbasic-test-strategy-review.yamlbasic-test-strategy.yamledge-condition-not-met.yamledge-insufficient-evidence.yamledge-role-boundary.yamledge-role-conflict.yamledge-unsupported-stage.yamlreview-test-report-review-raw-results.yamlreview-test-reporting-raw-results.yamlprompts/code-review.mdrequirements-analysis.mdtest-case-review.mdtest-case-writing.mdtest-report-review.mdtest-reporting.mdtest-strategy-review.mdtest-strategy.mdDetails
From the project READMEQA quality perspective
When to use
Use this at a requirements, strategy, review, test-case, or reporting stage when QA must assess testability, risk-based coverage, defect exposure, and quality risk from available evidence.
Inputs
stage(required):requirements-analysis,test-strategy,test-strategy-review,code-review,test-case-writing,test-case-review,test-reporting, ortest-report-review.- The declared stage inputs and any available requirement, code, test, defect, environment, or execution evidence.
Workflow
- Validate
stage. If it is missing or unsupported, return Not applicable, list supported stages, and request a validstage; do not generate filler conclusions. - Load and follow only the one Prompt mapped to that
stage; never combine stage Prompts. - Apply that Prompt's input threshold. When materials are insufficient, state facts, gaps, and needed evidence rather than inventing tests, defects, or quality conclusions.
- Produce a standalone QA quality report that separates facts, evidence, inference, missing evidence, and recommendations.
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 |
QA responsibilities and boundary
- Focus on testability, risk-based coverage, observability, test evidence, defect risk, untested scope, and quality risk.
- Treat only supplied material as fact; label inference and missing evidence. Never invent product intent, acceptance rules, implementation behavior, execution records, defects, or metrics.
- QA does not decide product intent, certify code correctness, or approve release. Without execution evidence, it must never infer that testing ran, passed, or verified quality.
Report contract
Unless returning Not applicable, include: Summary, Facts, Evidence, Inference, Testability, Risk-based coverage, Defects and quality risks, Missing evidence, Recommendations and next steps, Confidence. Tie every quality conclusion to evidence; classify risk as high, medium, or low with impact and uncertainty.
Pre-delivery check
- The
stageis valid and exactly one matching Prompt was loaded - Facts, evidence, inference, missing evidence, and recommendations are distinct
- Testability and risk-based coverage are assessed, or the reason they cannot be assessed is explicit
- No missing product intent, implementation fact, or execution result is reported as fact
- Without execution evidence, the report does not imply or claim executed, passed, or verified testing
On-demand loading and pitfalls
- Read only the mapped
prompts/file afterstageis valid. Readevals/for regression work, but never treat eval cases as project facts. - Do not replace evidence with a generic risk checklist, or present test recommendations, static reading, or stakeholder opinion as a passing execution result.
Report provenance
Keep the selected stage, a stable source_id, and supplied version in the report header. If a source ID is absent, declare a temporary local locator; if version is absent, write unknown rather than inventing it. Each finding has a stable finding_id, its source/evidence locator and status. Each action links its finding and specifies the evidence that would close it; owner, date and action status stay unknown unless supplied. These are standalone report fields, not a dependency on another Skill.
Qualitative risk anchors
Use impact, observed likelihood signals, and uncertainty together; this is judgment, not arithmetic multiplication or a new score. Unknown likelihood stays unknown.
| Risk | Impact and likelihood evidence | Uncertainty/action |
|---|---|---|
| High | Critical loss, blocking defect, or critical untested path; credible recurrence or unresolved exposure | Missing critical evidence prevents a confident low-risk claim; prioritize verification/escalation |
| Medium | Bounded impact or partial evidence with a plausible failure path | State the missing evidence and targeted follow-up |
| Low | Limited impact with supporting control evidence; no supplied critical exposure | State residual limits; do not equate low risk with release approval |