The /dr-design Command — Architecture Decided Before Code
How /dr-design explores three or more options for each design component, scores tradeoffs, commits to a decision, and documents the rationale — all before implementation begins.
Some implementation tasks are straightforward enough that a plan alone is sufficient guidance. Others involve decisions whose consequences ripple across multiple files, systems, or future changes. For those, committing to an approach without deliberate exploration is the most common source of architecture debt. The /dr-design command creates a structured space for that exploration.
The command is scoped to Level 3 and 4 tasks — those where complexity warrants more than a plan but where the design phase is distinct from the requirements phase. It runs after /dr-plan and before /dr-do, and its output is one or more creative documents stored in datarim/creative/.
What it does
The first step is classifying each component that needs a design decision into one of four types: UI/UX design, architecture design, data model design, or algorithm design. The type determines which activities apply — a data model design focuses on entity relationships and query optimization, while an architecture design focuses on component structure and system integration.
For each component, the command executes a creative phase: define the problem precisely, explore at least three distinct options, analyze the tradeoffs of each, make a decision with documented rationale, and write an implementation plan for the chosen option. Diagrams using Mermaid notation are included where the structure benefits from visualization.
For Level 3 and 4 tasks, a consilium pass runs after the individual component analysis. This assembles a panel of relevant agent perspectives — security, performance, testability, maintainability — and runs them through a structured debate. The panel converges on a recommendation, and any conflicts are resolved by an explicit priority ladder. The output includes a failure mode table: what happens if the chosen approach fails, and how that failure manifests.
One concrete example
A task to design the data model for a multi-tenant billing system produces a creative document with three schema options: a shared table with a tenant column, separate tables per tenant, and a hybrid with shared lookup tables and tenant-specific transaction tables. The tradeoff analysis shows the hybrid performs best at the expected tenant count but introduces migration complexity. The conseil panel raises a security concern about cross-tenant query leakage in the shared lookups. The final decision chooses the hybrid with an explicit row-level security policy on the shared tables, and the implementation plan includes the migration script and a V-AC (verification acceptance criterion) that verifies zero cross-tenant data leakage.
Where it fits in the pipeline
Design documents created here are read by /dr-qa Layer 2 (design conformance) after implementation. That layer checks whether the architectural decisions documented here were actually followed in the code, and flags any deviations for assessment. A deviation is not automatically a failure — sometimes implementation reveals a better path — but it must be documented so the choice is auditable.
The transition checkpoint before moving to /dr-do requires that every component has a clearly defined problem, at least three options analyzed, a committed decision, and an implementation plan. Skipping any of these in a complex task is the kind of shortcut that shows up as a hard-to-explain bug six months later.
Read about how design fits into the full workflow in what Datarim is, or continue to the /dr-do command that implements what the design committed to.