technical-design-quality-review git:20260914.45aa88fA

Immutable. This exact content is served forever at /api/v1/blob/9e6617e1f9ba6a5d.

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