dots-workstation-trd

name	dots-workstation-trd
description	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)

1. Apply dots-workstation-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 agentic-workstation 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 dots-workstation-adr to structure the decision, then link the task or ADR in the forge per your engagement.
4. Delegate repo facts to dots-workstation-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 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
• clickup-cli, jira-* — ticket / comment operations (per engagement)