/trd

name: trd
description: Technical Requirements Document generation through interactive interview
version: 3.1.0
argument-hint: "[initial-technical-context-or-project-name]"

Technical Requirements Document (TRD) Generator

Generate comprehensive **TECH_REQ.md** through collaborative technical discovery. This command transforms architectural ambiguity into clear technical decisions that feed directly into the EPCC plan phase.

**Opening Principle**: High-quality TRDs transform architectural ambiguity into clear technical decisions through collaborative discovery, enabling confident implementation with the right technology choices.

@../docs/EPCC_BEST_PRACTICES.md - Comprehensive guide covering sub-agent delegation, clarification strategies, error handling patterns, and technical requirements workflow optimization

What This Command Does

**Purpose**: Create Technical Requirements Document (TECH_REQ.md) that defines:

• Architecture patterns and component structure
• Technology stack with justified choices
• Data models and storage strategies
• Integration points and API design
• Security and compliance approach
• Performance and scalability plan

**Output**: `TECH_REQ.md` file

**Position in workflow**:

• **Optional input**: PRD.md (product requirements, if available)
• **This command**: Generate TECH_REQ.md through technical interview
• **Feeds into**: `/epcc-plan` (strategic implementation planning)

TRD Discovery Philosophy

**Opening Principle**: Discover technical requirements through **structured questions and collaborative dialogue**, not assumptions.

Core Approach

**✅ Do (Default Behavior)**:

• **Use AskUserQuestion proactively** for all technical decisions with 2-4 clear options
• Read PRD.md if available to understand product context
• Ask about architecture, stack, infrastructure aligned with product needs
• Present technology options with tradeoffs (not recommendations as facts)
• Match technical depth to project complexity
• Document rationale for every technical decision

**❌ Don't**:

• Assume tech stack without asking ("I'll use React and PostgreSQL" → Ask first!)
• Make technology recommendations without presenting alternatives and tradeoffs
• Skip reading PRD.md if it exists (product context informs technical decisions)
• Ask about implementation details (belongs in CODE phase)
• Force comprehensive TRD for simple projects (CRUD app ≠ distributed systems design)

**Remember**: You're discovering technical requirements, not implementing. Focus on WHAT technologies and WHY, defer HOW to CODE phase.

Discovery Objectives

**What we're discovering**:

1. **Architecture** (Patterns, service boundaries, component structure)

• Monolith? Microservices? Serverless? JAMstack? Hybrid?
• Design patterns to follow
• How components fit together

2. **Technology Stack** (Languages, frameworks, tools, libraries)

• Backend: Language + framework
• Frontend: Framework/library or vanilla
• Infrastructure: Hosting, deployment, orchestration
• Tooling: Build tools, testing frameworks, CI/CD

3. **Data Models** (Storage, schemas, relationships)

• Database choice with rationale
• Schema design approach
• Data relationships and migrations
• Caching strategy

4. **Integrations** (APIs, third-party services, authentication)

• API design (REST? GraphQL? gRPC? tRPC?)
• Authentication method (JWT? OAuth2? Session? Auth0?)
• Third-party services (payment, email, analytics, etc.)
• Webhooks and event handling

5. **Security** (Auth, compliance, data protection)

• Authentication & authorization approach
• Data protection and encryption
• OWASP considerations
• Compliance requirements (GDPR, HIPAA, SOC2, etc.)

6. **Performance** (Scalability, caching, optimization)

• Expected load and scaling strategy
• Caching layers (CDN, application, database)
• Performance budgets and monitoring
• Optimization priorities

**Depth adaptation**:

• **Simple project** → Focus on stack + data + basic security
• **Medium project** → Add integrations + performance + detailed security
• **Complex project** → Comprehensive architecture + compliance + high-scale design

Clarification Strategy

When to Use AskUserQuestion (PRIMARY METHOD)

**✅ Use AskUserQuestion for** (default for all technical decisions):

• **Architecture decisions**: "Monolith vs Microservices vs Serverless?"
• **Technology choices**: "Database: PostgreSQL vs MongoDB vs MySQL?"
• **Infrastructure decisions**: "Hosting: AWS vs GCP vs Azure vs Vercel?"
• **Authentication methods**: "Auth: JWT vs OAuth2 vs Session vs Auth0?"
• **API design**: "API style: REST vs GraphQL vs gRPC?"
• **Any decision with 2-4 clear options**

**Pattern**:

AskUserQuestion({
  questions: [{
    question: "What database technology fits your needs?",
    header: "Database",
    multiSelect: false,
    options: [
      {
        label: "PostgreSQL",
        description: "Relational, ACID compliant, complex queries, JSON support, mature ecosystem"
      },
      {
        label: "MongoDB",
        description: "Document store, flexible schema, good for JSON-heavy data, horizontal scaling"
      },
      {
        label: "MySQL",
        description: "Relational, widely supported, proven at scale, simpler than PostgreSQL"
      },
      {
        label: "DynamoDB",
        description: "AWS managed NoSQL, serverless, auto-scaling, simple key-value or documents"
      }
    ]
  }]
})

When to Converse Naturally (FALLBACK)

**✅ Use conversation for**:

• Open-ended exploration ("Tell me about your data model")
• Clarifying context ("What scale are we targeting?")
• Following up on answers ("You mentioned real-time features - how critical is sub-second latency?")
• Discussing custom/hybrid approaches not fitting 2-4 options

**❌ Don't use conversation for**:

• Standard technology choices (database, hosting, auth → use AskUserQuestion)
• Decisions already answered in PRD.md