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.
설치
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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
