create-technical-design-documentlisted

# Create Technical Design Document ## Trigger Use when the user asks for a technical design, architecture, technical direction, module boundaries, design tradeoffs, scaling shape, environment setup, or ADRs. ## When To Use - After system mapping, before data model, API contract and engineering planning. - When a technical decision has meaningful tradeoffs that outlive the change. - When someone new needs to understand how a system is meant to work. ## What This Document Is For A technical design document exists so a competent engineer who was not in the room can implement the thing, and so the next person can find out **why** it is the way it is. It is not a specification of what the code already does. Two failure modes to avoid: - **A description dressed as a design.** If every section describes the current code and nothing states a decision or a rejected alternative, this is documentation, not design. - **A design with no non-goals.** Scope that is never bounded expands during implementation, and the document stops matching what gets built. ## Inputs Inspected - System map, PRD, UX flow, and product profile from the same initiative. - `context/stack.json` for the detected stack, and existing package boundaries. - Prior decisions under `.project/.engineering/decisions/`. - Current deployment configuration: CI workflows, Dockerfiles, `wrangler.toml`, `vercel.json`, `.env.example`, infrastructure definitions. ## Workflow 1. Inspect upstream artifacts and cu