trdlisted

<!-- managed-by: harness-setup --> ## When to Trigger - "Write a TRD for..." - "Technical design for this feature" - "How should we build this — write it up" - "TRD for the [X] feature" ## Overview A Technical Requirements Document captures **how** a feature will be built: architecture, interfaces, data model, and constraints. It assumes the product-level "what and why" is already settled (see the `prd` skill) — don't re-litigate scope here, reference the PRD instead. A TRD is warranted when a feature touches multiple components/services, introduces a new integration or data model, or has technical trade-offs significant enough that reviewers need to weigh in before implementation starts. ## Workflow ### 1 — Ground it in the existing codebase, not a blank slate Before writing, identify how the codebase already solves adjacent problems — existing layering, naming, and patterns (see how neighboring features are structured). A TRD proposing a new pattern should say so explicitly and why the existing pattern doesn't fit, not silently diverge. ### 2 — Determine where it lives Store TRDs in `docs/trd/`, one file per feature: `docs/trd/<feature-slug>.md`. If a PRD exists for the same feature, link to it. If `docs/trd/` doesn't exist, create it. ### 3 — Write the TRD Use this format: ```markdown # TRD — <Feature Name> **Status:** Draft | Approved | Superseded by <link> **Date:** YYYY-MM-DD **Related PRD:** <link, or "none"> ## Summary One paragraph: what is being buil