Technical quality is more than tidy code. Availability, maintainability, recovery, and dependency boundaries decide whether a system can serve reliably over time. Evaluation must connect engineering traits to operational consequences.
The Technical Quality Perspective Skill assesses architecture and operational signals together, avoiding isolated code metrics that hide fragility.
The payment-callback example ties timeout, retry, idempotency, tracing, and rollback evidence to observable runtime consequences.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with Technical quality perspective.
Read the source Skill first
The main prompt covers Required inputs and gate, Technical assessment, Boundary and output, Inputs and workflow, Responsibilities and boundary. Those headings are navigation; the project artifacts still provide the facts.
This Skill has no separate examples directory. The sample below is derived from its entry point, main prompt, and eval constraints.
Related Skills
Technical Quality Perspective connects code and configuration to runtime consequences. These Skills can follow when a risk needs more investigation or verification:
| Skill | When to use it | What it adds |
|---|---|---|
| Performance Bottleneck Analysis | Latency, throughput, or resource trends show degradation | Forms bottleneck hypotheses across requests, dependencies, resources, and time |
| Root Cause Analysis | Several symptoms exist and the causal chain needs testing | Separates facts, assumptions, and counter-evidence into a testable path |
| Production Verification | A fix has shipped and its real impact needs checking | Verifies key metrics, alerts, rollback, and stop conditions |
| Multi-Role Quality Synthesis | Technical evidence must be reviewed alongside Product, QA, and UX reports | Preserves sources, conflicts, and minority high-risk findings |
| Project Delivery Perspective | A technical gap affects scope, dependencies, or release date | Connects technical actions to owners, milestones, and fallback options |
What the technical perspective contributes across the workflow
Technical Quality Perspective can cover all eight development stages, but answers technical-quality questions only. A passed code review does not prove tests passed, and a target release date does not lower the evidence threshold for runtime claims.
| Development stage | What to check | What to give the team |
|---|---|---|
| Requirements analysis | Whether API, data, dependencies, performance, compatibility, observability, and recovery constraints are defined | Technical facts, constraint gaps, questions, and confidence |
| Test strategy | Which failure modes, loads, recovery paths, and runtime signals need verification | Technical coverage, evidence threshold, and unverified assumptions |
| Test strategy review | Whether high-risk dependencies, degradation, rollback, or telemetry were omitted | Findings, impact, actions, and severity basis |
| Code review | Whether code identity and diff are traceable, and whether timeout, retry, idempotency, and logging have evidence | Static findings, runtime risk, and smallest evidence-gathering action |
| Test case writing | Whether failure injection, boundary inputs, migrations, and expected signals can become executable steps | Technical prerequisites, observable expectations, and recovery checks |
| Test case review | Whether cases reproduce failure and distinguish logs, metrics, and business outcomes | Gaps, indeterminate cases, and revisions |
| Test reporting | Whether version, time window, load, logs, metrics, traces, and exit status are recorded | Run facts, static observations, missing evidence, and technical risks |
| Test report review | Whether the conclusion connects code clues to runtime signals and whether recovery was actually exercised | Findings, impact, limits, and next verification |
A code review has a hard gate: include code identity and a reviewable change. “Please review this code” without a commit, diff, or file reference is not traceable technical evidence.
Connect service changes to runtime consequences
When reviewing a service change, consider architecture, observability, recovery, and rollback cost together.
| Technical issue | Evidence | Runtime consequence | Next action |
|---|---|---|---|
| External call has no timeout | Client configuration and dependency SLA | Threads or connections may stay occupied | Add a timeout, bounded retries, and an alert |
| Failure path lacks traces | Logs contain only a local request ID | Diagnosis requires manual correlation | Propagate a trace ID and use structured logs |
| Migration has no rollback | Migration script and rehearsal record | Version rollback may stall | Add a rollback script and rehearse recovery |
| Shared cache has no invalidation signal | Cache configuration and hit-rate trend | Stale data may continue to spread | Monitor invalidation and define cleanup |
A technical conclusion should connect a code characteristic to an observable and recoverable runtime consequence.
Technical review example: membership payment callbacks
The example follows a membership-upgrade change through development. It is hypothetical; replace placeholders with the actual version, runtime window, and evidence.
| Development stage | Technical question | Evidence to retain | Handoff |
|---|---|---|---|
| Requirements analysis | Are callback timeout, duplicate notification, idempotency key, and order-state transitions defined? | API contract, state diagram, dependency SLA | Technical constraints and missing rules |
| Design | How are timeout, retry limit, circuit breaking, trace propagation, and rollback implemented? | Design diagram, error-handling contract, recovery steps | Reviewable design assumptions |
| Code review | Does the PR set a timeout? Could retries amplify traffic? Can logs be linked to the order? | PR, commit, diff, static-check results | Static findings and smallest runtime check |
| Test execution | Can the system observe and recover from downstream latency or duplicate notifications? | Run ID, injected condition, logs, metrics, traces | Verified and unrun items |
| Report review | Does the conclusion apply only to this version and time window? | Report, rollback rehearsal, alert record | Scoped conclusion and repair owner |
For example, TECH-42 may record “no client timeout configuration was found in commit abc123.” That remains a static observation. If RUN-42 records timeout counts, traces, and recovery under a defined latency-injection condition, it adds runtime evidence. Do not merge both into an unexplained “stability passed.”
Keep observations, inferences, and gaps separate:
stage: test-report-review
source_version: build-42
dependency: payment-callback
time_window: [2026-09-24T10:00:00Z, 2026-09-24T11:00:00Z]
observed:
- source_id: PR-42
statement: No timeout configuration was seen in the callback client
evidence: diff-link-or-file
status: static_observation
- source_id: RUN-42
statement: The latency-injection scenario has not run
evidence: run-record
status: not_run
inference:
- Verify whether downstream latency keeps connections and threads occupied
missing_evidence:
- [timeout-count, trace-id, rollback-duration]
action:
owner: Payment service lead
next_action: Inject a timeout and retain logs, metrics, and traces
status: pendingThis structure can go to Multi-Role Quality Synthesis. Keep the technical material in TECH-42, QA execution status in QA-42, and let Project Delivery Perspective track the owner and due time. Do not collapse those responsibilities into one conclusion.
Align runtime signals before drawing a conclusion
Technical risk needs corroborating signals; one code metric cannot represent system stability.
| Conclusion | Signals to compare | Review action |
|---|---|---|
| Dependency is slower | p95/p99, timeout count, thread pool, downstream errors | Align traces and metrics within the same time window |
| Recovery is insufficient | Rollback duration, data checks, alert delivery time | Rehearse recovery in an isolated environment |
| Resources are near capacity | CPU, memory, connection pool, queue depth | Retest under representative load and retain a baseline |
For each conclusion, list its sources, time window, and unverified assumptions. The Skill organizes evidence; the technical owner accepts risk or schedules the fix.
Adaptable prompt
Use the technical-quality-perspective Skill.
Stage: test report review (test-report-review)
Task: Review a membership payment-callback change for runtime risk and recovery evidence
Version and environment: [requirement / build / environment]
Inputs: [PR, diff, logs, metrics, traces, run records]
Scope: [services and callback paths in scope]
Constraints: [accounts, data, time, compliance]
Separate static observations, runtime evidence, inferences, and missing evidence. Record source IDs, version, time window, impact, owner, and the smallest next verification. Do not turn a code observation into a runtime claim or release approval.Keep the technical conclusion within its evidence
A concise technical summary still needs facts, evidence, finding, impact or severity, missing information, and actions. Keep code observations, runtime evidence, and release decisions separate.
Who should use this Skill
Engineering and SRE teams can use it to review service changes, dependency behavior, observability, and recovery. QA and release owners can use its evidence boundaries when interpreting what a run did and did not verify.
Review a technical handoff
| Review item | What to retain | If missing |
|---|---|---|
| Code identity | Commit, diff, file, and review scope | Treat the claim as untraceable |
| Runtime identity | Version, environment, load, and observation window | Limit the conclusion to static analysis |
| Failure evidence | Injected condition, logs, metrics, trace, and recovery record | Keep runtime behavior unverified |
| Risk and action | Impact, severity basis, owner, and next verification | Leave risk open |
| Decision boundary | Technical evidence separated from risk acceptance and release approval | Route the decision to its accountable owner |
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/technical-quality-perspective -gInvoke it with “Use the technical-quality-perspective Skill,” then attach the real artifacts.
Common questions
Why check runtime signals after code review passes?
Timeouts, resources, retries, and recovery often appear only at runtime. Code review gives clues; runtime signals verify consequences.
What if monitoring data is incomplete?
Name the unobservable risk and the smallest log, metric, or trace to add, then decide whether work can continue.
When can a technical risk be closed?
After the runtime consequence is verified, recovery has been rehearsed, and the owner confirms the residual risk.
Does this Skill make architecture decisions?
No. It organizes evidence and options; the team makes trade-offs against cost, goals, and responsibility.
Use a real PR, diff, and runtime record to produce a Technical Quality Perspective assessment. The fragments provide structure; project evidence must come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Awesome QA Skills: Technical quality perspective Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-workflows/technical-quality-perspective
- Technical quality perspective Skill details:https://inaodeng.com/en/qaskills/technical-quality-perspective/