design-it-twice

Design It Twice

When invoked with $ARGUMENTS, treat the argument as the design problem to explore. Do not assume a solution. Start from the problem statement and generate at least two fundamentally different approaches independently. If the user or the codebase supplied a design, dispatch the clean-room-alternative agent (see Isolation Mode below) rather than trying to produce a second attempt yourself — a design already sitting in your context contaminates anything you write next, no matter how deliberately you try to ignore it. A design you drafted yourself while working on a fresh problem does not count as a supplied design: for a fresh problem, generate the alternatives directly. Then compare all approaches on concrete criteria.

This skill has two modes. For a fresh problem, where the user supplied no design, generate and compare alternatives directly, using the forcing technique below to push past your first idea. When the user or the codebase supplied a design, dispatch the isolated agent described below to produce an independent second attempt that isn't anchored to the first. Either way, the first idea is unlikely to produce the best design, not because the designer isn't smart, but because the problems are genuinely hard.

When to Apply

• Before committing to a class, module, or API design
• When choosing between architectural approaches
• When an interface feels awkward but "good enough"
• When writing a design document or RFC
• When you catch yourself thinking "this is obviously the right way"

When NOT to Apply

• Trivial decisions with negligible consequences
• Well-established patterns where the design space is explored
• Bug fixes that don't change the interface
• Cost of the exercise should be proportional to cost of getting the design wrong

The Procedure

1. Generate at least two fundamentally different approaches, not variations on one idea. If both share an interface shape, they're variations. Push until the second makes you uncomfortable.