Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/ai-protocol-kit/llms.txt

Use this file to discover all available pages before exploring further.

Pre-Task Expansion Protocol v1 is a five-step pre-response ritual that runs before the AI answers any task. Its purpose is to prevent the most common failure in AI-assisted reasoning: collapsing immediately to the most obvious interpretation of a problem and producing a well-formed answer to the wrong question. The protocol does not delay the response — it restructures the path to it, forcing the AI to surface alternative framings, lay them flat without hierarchy, find what belongs together, and only then go deep on what is actually most relevant.

​
What It Is

The protocol is a mandatory sequence. It runs before the AI responds to any task where the problem might collapse too quickly, carry unstated ambiguity, or have an obvious answer that feels too easy. The sequence cannot be skipped or compressed.
This protocol is about problem framing, not solution generation. Steps 1–4 operate entirely at the level of how the problem is read. Solutions come after Step 5.

​
When to Use It

Fast Collapse Risk

The task has an obvious, direct answer — but “obvious” often means “first framing wins.” Use this protocol to check whether the obvious answer is actually right.

Unstated Ambiguity

The problem statement looks clear on the surface but may carry hidden assumptions about what is actually being asked. The obvious reading might be one of several valid interpretations.

Underspecified Tasks

The task is vague, high-level, or contains a request that could be satisfied in structurally different ways — not just different implementations of the same shape.

​
The Five Steps

The protocol defines exactly five steps. Each must complete before the next begins.
1

OBVIOUS SOLUTION

State the most direct, structural solution to what was asked. One sentence. Get it out.The purpose of this step is to name the obvious answer explicitly — not to act on it. Making it visible is what allows the next steps to challenge it.
2

ALTERNATIVE READINGS

Before touching solutions, reread the problem. Generate 3 alternative ways this problem could be framed — not solutions, framings.Each alternative framing should make the obvious solution look incomplete or wrong. If none of the three framings challenge the obvious solution, they are not doing their job.
3

LAY FLAT

Put the obvious solution and the 3 alternative framings side by side. No hierarchy. No preference. No winner yet.This step prevents the obvious solution from carrying invisible weight into the grouping phase. Everything is treated as equally candidate until the next step resolves it.
4

GROUP

Look across what is flat. Find what belongs together. Name the groups.Do not force groupings — if something stands alone, let it stand alone. The goal is to find natural structure in the set of framings, not to produce a tidy taxonomy.
5

BUILD DOWN

On the group that is most relevant to the actual task, go deep. This is where the work happens. Everything else stays visible but parked.“Parked” means: acknowledged, not discarded, not pursued. It remains available if the direction shifts.
Only after this full sequence does the AI respond to the task.

​
Why This Works

The protocol separates two operations that AI conflates by default: problem framing and solution generation. When a task arrives, AI pattern-matches to the most familiar framing and generates a solution for that framing. If the framing is wrong, the solution is wrong — even if it is well-executed. By forcing ALTERNATIVE READINGS before any solution work, the protocol prevents the first framing from winning by default. By laying everything flat in Step 3, it removes the implicit weight that “obvious” carries. By grouping in Step 4, it finds whether the alternatives cluster around a different core question. By building down in Step 5, it ensures depth goes to what actually matters — not to what arrived first.

​
Worked Example

Task prompt: “Help me improve communication on my team.”
Obvious solution: Set up a regular team meeting cadence with clear agenda templates and action item tracking.
This is what the protocol produces before the AI gives any response: an expanded view of the problem space, a reason to distrust the obvious answer, and a direction that goes to the actual root rather than the nearest solution.

​
What This Is Not

Pre-Task Expansion is not a brainstorming tool and not a stalling mechanism. It runs fast and produces a structured view, not an open-ended exploration. If the obvious answer survives all five steps intact, that is a valid outcome — the protocol confirmed it rather than assumed it. It is also not the same as System Reading Protocol. Pre-Task Expansion is for reframing an ambiguous task before acting on it. System Reading Protocol is for understanding what a real system actually does versus what it claims to do. Use Pre-Task Expansion when the problem framing is at risk. Use System Reading when the subject is a real system with observable behavior.

Build docs developers (and LLMs) love

Get started for freeTalk to us