technical-blueprint

## Purpose Produce a Technical Design Document (TDD) that captures the engineering design of a specific feature or component with enough detail that any qualified engineer on the team can implement it correctly. This document is a **thinking tool first, an artifact second** - the process of writing it surfaces gaps before they become production bugs. Unlike an architecture document (what the system is), a blueprint specifies **how a specific piece will be built**. ## Input **Works best with:** The name of the feature, component, or change to be designed. **Also valuable:** The technical specification or requirements document, existing codebase context, known constraints (performance targets, security requirements, API contracts that must be maintained). **Example invocation:** `Write a technical design document for adding TOTP-based two-factor authentication to the admin login flow. We use PHP 8.3, PDO/MySQL, and Twig templates. The TOTP secret must be stored encrypted. Recovery codes must be supported.` ## Key Concepts ### Design Doc Philosophy (Google/Stripe Standard) A design doc is: - **Short as possible, long as necessary.** If it takes more than 45 minutes to read, it is too long. - **Trade-off focused.** The Alternatives Considered section is mandatory. It proves you evaluated options. - **A conversation starter.** Share early and revise often. A design doc is not a contract. - **Living.** Update it as the implementation evolves. Stale design docs are worse than...