/dr-design

Overview

/dr-design is the creative exploration stage for Level 3-4 tasks. The Architect agent classifies each component into a design type (UI/UX, Architecture, Data Model, or Algorithm), explores multiple options, analyzes tradeoffs, makes documented decisions, and produces implementation plans with diagrams.

Usage

/dr-design

What It Does

1. Task Resolution — applies the Task Resolution Rule to determine which task to design for (from argument or disambiguation when multiple tasks are active).
2. Context Loading — reads tasks.md and systemPatterns.md for the resolved task and project patterns.
3. Classify Design Type — determines whether each component needs UI/UX design, architecture design, data model design, or algorithm design.
4. Creative Exploration — for each component: defines the problem, explores 3+ options with different approaches, analyzes tradeoffs (pros, cons, complexity, effort), makes a decision with clear rationale, and documents an implementation plan.
5. Visualization — includes Mermaid diagrams where they help clarify structure or flow.
6. Consilium Panel (L3-4) — assembles a multi-agent panel for complex decisions, runs through SCOPE, ASSEMBLE, ANALYZE, DEBATE, CONVERGE, DELIVER pipeline with conflict resolution.
7. Document Creation — saves to datarim/creative/creative-[task_id]-[type]-[name].md with the full decision record.

Arguments

None. Operates on the currently active task (resolved via Task Resolution).

Output

Creates: datarim/creative/creative-[task_id]-[type]-[name].md. Updates: datarim/tasks.md.

Design Types

• UI/UX Design — user flows, component hierarchy, interaction patterns, visual principles
• Architecture Design — component structure, data flow, system integration, interface design
• Data Model Design — entity relationships, schema design, validation rules, query optimization
• Algorithm Design — complexity analysis, efficiency optimization, edge cases, scaling

Transition Checkpoint

Before proceeding to implementation:

• Problem clearly defined for each component
• 3+ options analyzed with tradeoffs
• Decision made with documented rationale
• Implementation plan included
• tasks.md updated with design decisions

Example Session

> /dr-design

Design type: Architecture Design
Component: Notification delivery system

Problem: How to deliver real-time notifications
to 10K+ concurrent users reliably?

Option A: WebSocket per-connection (Socket.io)
  + Simple, bidirectional, wide library support
  - Memory-heavy at scale, sticky sessions needed

Option B: Redis pub/sub + SSE
  + Horizontally scalable, simpler client
  - Unidirectional, reconnection handling

Option C: Message queue (RabbitMQ) + WebSocket
  + Decoupled, reliable delivery, scalable
  - Infrastructure overhead, higher complexity

Decision: Option C — best fit for reliability
requirements and planned growth.

Saved: datarim/creative/creative-NOTIF-0001-architecture-delivery.md

Related Commands

• /dr-plan — previous stage: implementation planning
• /dr-do — next stage: execution