technical-design-review

Reviews TypeScript and Node backend design documents for ownership seams, trade-offs, and missing proof.

1|1|Updated Apr 8, 2026
One-click install
npx skills add https://github.com/GonkaGate/opencode-setup --skill technical-design-review-gonkagate
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: technical-design-review
Source: https://github.com/GonkaGate/opencode-setup/tree/main/.agents/skills/technical-design-review
Command: npx skills add https://github.com/GonkaGate/opencode-setup --skill technical-design-review-gonkagate

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Reviewing RFCs, ADRs, and architecture proposals for TypeScript/Node backends often produces generic feedback that misses the real risks. This Skill performs a disciplined, read-only design review that starts from architecture, activates only the seams the design actually touches, and separates true flaws from deliberate trade-offs and missing proof. ## Core Features & Use Cases - Architecture-first review: Evaluates ownership boundaries, dependency direction, composition root, config and error boundaries, and module publication surfaces before anything else. - Seam-activated depth: Pulls in contract, Fastify runtime, Prisma/PostgreSQL, Redis, reliability, security, performance, or test-proof analysis only when the design genuinely crosses those seams. - Calibrated findings: Classifies every point as a finding, trade-off, missing proof, or acceptable assumption, with explicit severity, confidence, and the smallest useful correction. - Use Case: Given an ADR proposing a new caching layer with Redis, the review identifies whether Redis acts as cache, lock, or queue, challenges replay and TTL semantics, and states exactly what proof is still missing before the design is ready. ## Quick Start Ask the AI to review the attached backend design doc or ADR using the technical-design-review skill and report material findings, trade-offs, and missing proof.

Frequently Asked Questions about technical-design-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a backend architecture design doc before implementation?

Provide the design doc, ADR, or RFC and request a technical design review. The review starts from architecture ownership and dependency direction, activates only the seams the design touches, and reports findings, trade-offs, and missing proof with confidence levels.

What should a design review for a Node.js backend cover?

It should cover module ownership, composition root, config and error boundaries, and publication surfaces first, then adjacent seams like API contracts, Fastify lifecycle, Prisma migrations, Redis semantics, reliability, security, and performance only where the design actually crosses them.

When should I use a single-topic review instead of a full design review?

Use a single-topic review such as api-contract, prisma-postgresql, or redis-runtime review when one seam clearly dominates and deeper specialist detail matters more than cross-seam synthesis. Use the full design review when a proposal spans multiple backend seams.

Can this review run without a complete design document?

It requires concrete design material such as a spec, ADR, schema sketches, flow descriptions, or a proof plan. If that material is missing, the review downgrades conclusions to missing proof or open design questions instead of inventing detail.

Does the design review write code or implementation plans?

No, the review is strictly read-only and stays at design scope. It recommends the smallest design correction or next proof step, but implementation planning and coding are handed off to separate planning and coding skills.