Technical Design Quality Review - QA Skill Library

Why this Skill

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

Use it for ADRs, component/data-flow designs, technical proposals, and non-functional constraints.
Do not review implementation that was not supplied or claim build, compatibility, security, or performance tests passed.
Do not infer consistency, capacity, latency, SLOs, owners, or recovery behavior from component names.
Each TD-## includes topic, source/evidence, impact, priority, gap action, owner role, decision question, and validation method.
Checking that a diagram exists without checking boundaries, failures, or recovery.

When to use

Use this Skill

Use it for ADRs, component/data-flow designs, technical proposals, and non-functional constraints.
Use it to identify failure paths, dependency assumptions, compatibility risks, and evidence gaps.
Use it when an incomplete design still needs a bounded implementation-readiness pass.

Common pitfalls

Checking that a diagram exists without checking boundaries, failures, or recovery.
Treating “supports high concurrency” or “has monitoring” as a verification criterion.
Turning technical recommendations into an approved architecture or release conclusion.

Input

Minimum Input

Read `prompts/technical-design-quality-review.md` and audit objective, version, scope, sources, and success criteria.

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

01Read prompts/technical-design-quality-review.md and audit objective, version, scope, sources, and success criteria.
02Classify input as known, missing, conflicting, stale, out_of_scope, and assumptions.
03Build a design-coverage matrix; bind each material gap to a TD-##, minimum evidence, impact, priority, and validation method.
04Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade a design claim to an implementation result.

View full output structure

05Deliver bounded conclusions and evidence actions when information is missing instead of filling gaps with generic architecture knowledge.

How It Works

01Read prompts/technical-design-quality-review.md and audit objective, version, scope, sources, and success criteria.
02Classify input as known, missing, conflicting, stale, out_of_scope, and assumptions.
03Build a design-coverage matrix; bind each material gap to a TD-##, minimum evidence, impact, priority, and validation method.
04Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade a design claim to an implementation result.
05Deliver bounded conclusions and evidence actions when information is missing instead of filling gaps with generic architecture knowledge.

Install & Quick Start

Install command / SHELL

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

technical-design-quality-review.prompt

@skill technical-design-quality-review

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

Additional context:
[Paste project context or requirement]

---
name: technical-design-quality-review
description: Use this skill when an architecture note, ADR, component design, or technical proposal needs an evidence-bounded quality review before implementation; triggers include technical design review, design readiness review, and non-functional design audit.
---

# Technical Design Quality Review

Review a technical design before implementation for boundaries, dependencies, failure modes, data consistency, security, performance, observability, compatibility, maintainability, and verification readiness. It produces `TD-##` findings and validation preparation; it does not review unsupplied code or approve architecture.

## When to Use

- Use it for ADRs, component/data-flow designs, technical proposals, and non-functional constraints.
- Use it to identify failure paths, dependency assumptions, compatibility risks, and evidence gaps.
- Use it when an incomplete design still needs a bounded implementation-readiness pass.

Do not use it to run builds, tests, production probes, or choose a final architecture for a Human.

## Output Format Options

- Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
- Do not present a structured format or static inventory as execution, pass, approval, or release evidence.

## How to Use

1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.

## Workflow

1. Read `prompts/technical-design-quality-review.md` and audit objective, version, scope, sources, and success criteria.
2. Classify input as `known`, `missing`, `conflicting`, `stale`, `out_of_scope`, and `assumptions`.
3. Build a design-coverage matrix; bind each material gap to a `TD-##`, minimum evidence, impact, priority, and validation method.
4. Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade a design claim to an implementation result.
5. Deliver bounded conclusions and evidence actions when information is missing instead of filling gaps with generic architecture knowledge.

## Core Constraints

- Do not review implementation that was not supplied or claim build, compatibility, security, or performance tests passed.
- Do not infer consistency, capacity, latency, SLOs, owners, or recovery behavior from component names.
- Each `TD-##` includes topic, source/evidence, impact, priority, gap action, owner role, decision question, and validation method.
- Design presence proves only that a document exists; execution evidence requires identity, time, environment, inputs, and raw results.

## Reference Files

- Always read `prompts/technical-design-quality-review.md` before producing a review.
- For regression, read `evals/eval.yaml` and its cases; a static design review is not system execution.
- For trigger checks, use `evals/trigger-prompts.csv` and `evals/local-rules.json`; without a selection trace report `BLOCKED`.

## Best Practices

- Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
- Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.

## Delivery Checklist

- [ ] Complete the six input-audit categories and state design scope.
- [ ] Cover boundaries, dependencies/failures, data, security, performance, observability, compatibility, maintainability, and verification readiness.
- [ ] Give every `TD-##` evidence, impact, owner, action, and validation method.
- [ ] Separate design claims, evidence-backed inference, recommendations, and Human decisions.
- [ ] Do not present document presence or static checks as implementation/runtime results.

## Common Pitfalls

- Checking that a diagram exists without checking boundaries, failures, or recovery.
- Treating “supports high concurrency” or “has monitoring” as a verification criterion.
- Turning technical recommendations into an approved architecture or release conclusion.