rnd-designlisted

# R&D Design Exploration ## Overview Explore architectural alternatives and produce a design spec before committing to a plan. The goal is to surface real trade-offs between approaches so the user can make an informed architectural decision — not to find the "right" answer on their behalf. **Core principle:** An architectural decision made without evaluating alternatives is a guess. Design exploration converts guesses into decisions backed by evidence. **Skill type:** Rigid — the approval gate and iteration cap are non-negotiable. Do not skip alternatives, do not collapse to a single approach, do not proceed to planning without explicit user approval. ## When to Use - Large tasks (multi-day, multi-feature) where the architectural approach is not obvious - When the user description leaves the implementation strategy open - When there are competing approaches with meaningfully different trade-offs (e.g., event-driven vs request-response, monolith vs microservices, SQL vs NoSQL) - When the orchestrator's scaling rules call for a design review gate (see `rnd-framework:rnd-orchestration`) - After Discovery/requirements gathering and before Decomposition/planning **When NOT to use:** - Small or well-defined tasks where the approach is already specified - When the user has already committed to a specific approach ("implement it using X") - When the task is a refactor with clear scope and no architectural ambiguity ## The Iron Laws ``` 1. ALWAYS generate 2-3 alternatives —