PRD to Technical Design

Problem

Turning a PRD directly into a design often produces docs that ignore the existing codebase, use inconsistent API or database naming, miss edge cases and failure paths, assume unclear requirements, or render diagrams in inconsistent styles. This skill is aimed at engineers who need a product requirement turned into an actionable technical design, not a generic solution narrative.

Workflow

It starts by reading a PRD from a URL or pasted text, checking reusable design history, and confirming the code scan scope. It selects a design template by complexity, then adjusts it after inspecting Controller, Service, data tables, API routes, shared utilities, and related middleware. It extracts core requirements, boundary conditions, exception scenarios, and non-functional requirements, then clarifies ambiguous points by priority instead of guessing. The output is a Markdown design document, saved under docs/tech-design/ by default, covering interfaces, database changes, risks, and schedule where applicable. Architecture diagrams use PlantUML and flow diagrams use Mermaid graph TD/LR, with new or modified nodes explicitly marked. After generation, it runs self-checks for naming, API path consistency, error codes, requirement coverage, exception handling, tech-stack alignment, and component reuse.

Boundaries

It fits existing backend or full-stack codebases, especially interface additions, table changes, state machines, or module extensions. If the PRD is thin, the link is unavailable, or the repo structure is unclear, the skill expects human confirmation or a narrower module path. It avoids introducing unfamiliar tech, avoids inventing requirements, and marks high-priority unresolved items for human review. If template files are missing, it falls back to a built-in standard structure.