WHAT — Draft and review a Technical Requirements Document (TRD) using the agentic-workstation template, typically from an agreed PRD. Covers architecture, data contracts, technical decisions, risks, and test strategy. English for technical artifacts and tickets unless the user asks otherwise.
WHAT — Draft and review a Technical Requirements Document (TRD) using the agentic-workstation template, typically from an agreed PRD. Covers architecture, data contracts, technical decisions, risks, and test strategy. English for technical artifacts and tickets unless the user asks otherwise.
TRD — Technical Requirements (WHAT)
Template:references/default-template.md — local reference, kept up to date with the agentic-workstation standard structure.
Default guardrails (before any final content)
Apply dots-workstation-output-handshake: confirm where the final TRD will live and that a human will review.
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 agentic-workstation standards.
A client doc hub with PRD/TRD cross-links requires matching document structure.
Instructions
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.
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.
For ADRs that block or explain design, use dots-workstation-adr to structure the decision, then link the task or ADR in the forge per your engagement.
For ticket updates, use the appropriate tool (clickup-cli, jira-*, etc.); keep task comments short with links to the Doc (per dots-workstation-workflow-generic-project).
What not to do
Do not dump the full external template into this skill; use references/default-template.md as the local canonical reference.
Do not skip risks and testing when the TRD is a handoff artifact.
References
dots-workstation-output-handshake — destination and review
references/default-template.md — local TRD template
references/example-unified-api.md — TRD example for a full API migration (see PRD link in that file)
references/example-api-migration.md — detailed TRD example with phases, architecture, and testing strategy
dots-workstation-prd — when work starts from product requirements
dots-workstation-spike — research findings used as design evidence
dots-workstation-adr — decision records linked from the TRD
dots-workstation-development-workflow — validation and traceability expectations
dots-workstation-incident — failure handling / incident implications when relevant
dots-workstation-workflow-generic-project — delivery gates and traceability
