trdlisted

# TRD — Technical Requirements (WHAT) **Template:** `references/default-template.md` — local reference, kept up to date with the standard structure. ## Default guardrails (before any final content) 1. Apply **`output-handshake`**: confirm **where** the final TRD will live and that a **human** will review. 2. Then follow the steps below. ## When to use - A **PRD is approved** (or the task is technical-only) and the team needs design-level agreement before build. - You need **API/data contracts**, component boundaries, and **test strategy** aligned to standards. - A client doc hub with PRD/TRD cross-links requires **matching** document structure. ## Instructions 1. **Open the TRD template** (`references/default-template.md`). Align sections: Scope, Architecture overview, Data model / API contracts, Technical decisions (link **ADRs** and spikes), Dependencies, Risks & constraints, Testing strategy, Implementation plan. 2. **Map from PRD:** user stories and AC from the PRD should appear as **addressed** in the TRD with clear technical response; if no PRD exists, state that explicitly and list assumptions. 3. For **ADRs** that block or explain design, use **`adr`** to structure the decision, then **link** the task or ADR in the forge per your engagement. 4. Delegate **repo facts** to **`assistant`** (conventions, CI, existing patterns); cite sources. 5. For **ticket updates**, use the appropriate tool (`clickup-cli`, `jira-*`, etc.); keep task comments **short** with links