Technical 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.

Use this Skill when its method fits the current quality task.

When to use

Use this Skill

Use this Skill when its method fits the current quality task.

Common pitfalls

No content is available for this Skill yet.

Input

Minimum Input

The current scope, available context, constraints, and evidence.

Recommended Input

Project goal
Test scope
Constraints

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

01An actionable result that distinguishes facts, assumptions, risks, and next steps.

Install & Quick Start

Install command / SHELL

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

technical-quality-perspective.prompt

@skill technical-quality-perspective

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

Additional context:
[Paste project context or requirement]

---
name: technical-quality-perspective
description: Use this skill when a technical quality perspective is needed for requirements, strategy, code, test cases, or reports; triggers include technical quality review, architecture review, and code review.
---

# Technical quality perspective

## When to use

Use this to assess technical quality from declared architecture, API, data, code, security, performance, compatibility, and observability evidence at a selected delivery stage.

## Inputs and workflow

- `stage` is required: `requirements-analysis`, `test-strategy`, `test-strategy-review`, `code-review`, `test-case-writing`, `test-case-review`, `test-reporting`, or `test-report-review`.
- Validate `stage`; if absent or unsupported, return **Not applicable**, list supported values, and request a valid stage. Load exactly one mapped Prompt only.
- For `code-review`, require both code identity (PR, commit, branch, release version, or equivalent) and reviewable changes (diff, files, or code). If either is absent, block review; do not infer findings or merge readiness.
- Apply the selected Prompt's applicability threshold. Treat supplied material as fact, label inference, and turn missing material into questions and actions.

| `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` |

## Responsibilities and boundary

- Cover architecture, APIs, data, compatibility, security, performance, observability, and maintainability only when relevant to the selected stage and supplied evidence.
- Produce technical findings with evidence, impact, severity, missing information, actions, and confidence. A gap supports a qualified risk, never an invented implementation, metric, vulnerability, or execution result.
- Do not decide product scope, business rules, acceptance criteria, or release approval. Do not claim code correctness, test execution, or passed testing without direct evidence.

## Report contract and self-check

Unless blocked or **Not applicable**, output: **Summary, Facts, Evidence, Technical findings, Impact and severity, Missing information, Questions, Actions and next steps, Confidence**.

- [ ] Valid stage and exactly one mapped Prompt
- [ ] Code review has code identity and reviewable changes, or is explicitly blocked
- [ ] Findings are evidence-backed; gaps and inference are labelled
- [ ] No product or test fact has been invented or changed
- [ ] Stage-relevant technical dimensions only; no passed-test or code-correctness claim without evidence

Read only the mapped Prompt after stage validation. Read `evals/` only for regression work, never as project evidence.