Design An Interface

Typical invocation points:

• A slice plan says "add module X" and the shape of X is not obvious.
• Two callers are about to grow coupled to an interface that has not been designed on purpose.
• A refactor surfaces a seam that needs to be re-cut deliberately.

<core_principle> RADICALLY DIFFERENT, NOT VARIANTS. Three designs with different method names are one design. Three designs that hide different things, expose different axes of control, or invert the caller/callee relationship are three designs. Enforce real divergence by assigning each sub-agent a constraint that would force a different shape.

INTERFACE, NOT IMPLEMENTATION. Do not estimate effort. Do not argue about how hard it is to build. Argue about how the interface behaves from the caller's side and what it hides internally. </core_principle>

Step 1: Gather requirements

Before spawning anything, answer in the conversation:

• What problem does the module solve?
• Who calls it? (other modules, external users, tests)
• What are the key operations?
• What constraints exist? (performance, compatibility, existing patterns)
• What should stay hidden inside vs be exposed?

If the user did not supply all of these, ask — one round, 1–3 questions max, per the ask-vs-infer rule.

Step 2: Spawn parallel design agents

Use Agent(subagent_type=general-purpose) for 3–4 agents in one message so they run concurrently. Each agent gets the same requirements brief plus one divergent constraint:

• Agent 1: "Minimize method count — 1 to 3 entry points max."
• Agent 2: "Maximize flexibility — support many extension points and composition."
• Agent 3: "Optimize for the single most common caller — make the default case trivial and the advanced case possible."