Idea → Hypothesis → Proof Design (Orchestrator)

Take a raw idea and walk it to a formal, defensible claim with a proof strategy: sharpen the hypothesis, isolate what must be true, state the claim precisely, sketch the proof, and audit it before the user sinks weeks into a full write-up. This skill routes between singletons — it does not produce the stress-test, the proof sketch, or the audit itself.

Contrast with siblings:

• learn-new-topic / deep-understanding — understanding existing work. Here the object is the user's own idea and doesn't exist yet.
• gap-finder — starts from an existing paper's weakness. Use that to source an idea; use this to develop one you already have.

Before You Start: Capture the Raw Idea

Ask only what you can't infer. You need:

• The idea, in one sentence — even if vague. You'll sharpen it in stage 1.
• The setting — what mathematical/empirical objects it concerns (the formalism it lives in).
• What "true" would mean — is the user after a theorem, a bound, a guarantee, an impossibility result, or an empirical regularity they want to explain? This sets whether the path is proof-design or experiment-design.

If the user actually wants empirical validation rather than a proof, route to research-idea-stress-test → experiment-design instead and say so.

The Pipeline