Decompose Prompt

Decompose Prompt

Take a prompt that's trying to do too much and break it into a pipeline of simpler prompts, each with a clear input, output, and handoff to the next step.

This picks up where prompt-optimize stops. When the fix isn't better wording but better architecture — fewer responsibilities per prompt, explicit intermediate outputs, and the right model tier at each step — decomposition is the move.

Behavior Constraints

<output_contract>

Present the decomposition as:

• Current prompt — what the prompt is trying to do, and why it's too much for a single call (list the distinct responsibilities it's juggling)
• Pipeline — an ordered sequence of steps, each containing:
  • Step name — short label (e.g., "extract", "classify", "generate")
  • Input — what this step receives (original user input, or output from a previous step)
  • Task — what this step does, in one sentence
  • Output — what this step produces, with the expected format
  • Model tier — small/fast, mid-tier, or frontier, with a one-line justification
• Handoffs — how output from each step feeds into the next. Call out where format mismatches could cause failures (e.g., step 1 produces free text but step 2 expects JSON)
• Tradeoffs — what the pipeline gains (reliability, debuggability, cost) and what it costs (latency from multiple calls, added complexity, potential for error propagation)
• Prompt sketches — a brief prompt draft for each step, focused enough to show the shape but not fully polished

</output_contract>

<completeness_contract>

The task is complete when each step in the pipeline has a single clear responsibility and the handoffs between steps are explicit. If the original prompt doesn't actually need decomposition — it's doing one thing and doing it poorly — say so and recommend prompt-optimize instead.

</completeness_contract>

<reasoning_rules>

• Decompose by responsibility, not by length. A long prompt doing one thing well doesn't need splitting. A short prompt juggling extraction, reasoning, and formatting does.
• Each step should be independently testable. If you can't write an eval for a step without running the whole pipeline, the decomposition is wrong.
• Prefer fewer steps. Two steps that each work reliably beats four steps with fragile handoffs. Only add a step when combining its responsibility with another measurably degrades output.
• Use the cheapest model tier that handles each step. The extraction step probably doesn't need a frontier model. The reasoning step might.
• Flag error propagation risks. In a pipeline, a bad output from step 1 cascades. Identify where validation or retry logic between steps would help.

</reasoning_rules>

Workflow

1. Ask the user for the prompt to decompose if not already provided. Accept pasted text or a file path. Optionally ask what's going wrong — understanding the failure mode helps identify which responsibility to split off.
2. Identify the distinct responsibilities the prompt is handling.
3. Design the pipeline and present the output per the output contract above.