Prompt Chaining Explained: Why Handoffs Need Checks

Chained prompts work because each step gets the full result of the one before, or so the common advice goes. AuricIDE instead gives each step its own prompt, followed by a cleaned, capped tail of the previous step's terminal output.

Does each chained step get the full result?

No. A Skill Combo passes a terminal tail, not the previous session's complete result. Prompt chaining means running prompts in a fixed order, with one step's output supplied to the next. That leaves open what counts as output.

Picture a database migration with three steps: plan, implement, review. This is an illustration, not a recorded incident. The planning agent lists the tables it found and finishes with "plan ready." One table is missing from the list. The implementation agent receives that claim and changes only the tables in the plan, without opening the schema again. Its command exits successfully. The migration is still incomplete. Nothing flagged it.

The review step may catch the omission. Maybe. By then, the implementation has already changed files. The problem started earlier: a statement about the plan stood in for a check against the schema.

The check that mattered never happened, because the plan was treated as a fact.

A green exit code can't settle that. Agent monitoring helps you find a process that needs attention, but a process can finish successfully and still hand back incomplete work.

Should the handover be a full transcript or a summary?

Neither helps much. Why? A transcript keeps the mistaken claim among correct observations, and the next agent still has to find it. A neat summary saves that reading. It can also make an untested claim sound settled. A tidier note saying the oven is off doesn't replace looking at the switch.

A chain handover should be a short lead the next step has to check, not a record it can trust, because a trusted summary carries the previous step's mistakes forward. The Prompt Sapper paper treats a chain of prompts as something to engineer with ordinary software practice. Separate prompts let you give each worker a narrow task and a clear check. They don't certify its answer.

In the migration, the implementation prompt needs its own check: compare the plan with the schema before changing data. The review prompt needs another: inspect the resulting changes and name any table left behind. Those checks belong to the tasks. A handover can't do them.

What does AuricIDE give the next step?

Each step starts with its own prompt. Beneath it sits a labelled block with the tail of the previous step's terminal output. The block says the text may be cut off and tells the receiving agent to check the working tree before relying on any detail in it. No structured result object passes between steps, only text.

Receiving rule: Check the working tree before treating a handover claim as a fact.

Before the tail is attached, AuricIDE removes terminal color codes and some interface lines. It drops lines with no letters. It collapses repeated redraws. Then it keeps the newest lines that fit within 2,000 characters. If one line alone is longer than that, only its end survives. The handover gets small. It doesn't get true.

The handover is plain terminal text. So it doesn't depend on which agent CLI produced it. A planning step can inspect without editing. An implementation step can have edit permissions. A review step can run on another CLI. Each step in a combo is an agent skill with a prompt, and it can set its own provider, model and permission mode.

Can steps run together?

Combo steps run strictly one after another. No overlap. A step that exits with an error ends the chain, and the later prompts never run. Success only lets the next step start. It says nothing about whether the migration is complete.

A combo stays inside one project. It doesn't span repositories. There is no parallel branch. Independent agents run side by side in the Fleet view instead, but a Skill Combo always has exactly one current step.

What does a 2,000-character tail cost?

Older output disappears. Once the cleaned text passes the cap, it is gone. That may include the warning, the command that exposed the missing table, or the reason an edit stopped halfway. A long error dump can fill the whole budget. The next agent sees the end of the session, not an account of it.

The label helps. But it can't bring back a dropped line. Gone is gone. Nor can cleaning spot a false claim, because no filter checks the schema. The receiving prompt has to name what to inspect, and the agent then has to inspect it in the project itself.

So end each step with a compact status: files changed, checks run, work still unresolved. Put long diagnostics before it, so the status stays in the tail. That is a prompt choice, not a guarantee. Agents misreport too. The agent writes the status itself. It can misstate what it did.

End with a compact status, not another dump of the session.

When is another step worth starting?

Chain when the stages need different permissions or different strengths: planning without edits, implementation with edits, then independent review of the changed files. Every extra step is another agent start. It is also another place for a wrong claim to enter.

Keep one session when the task depends on the whole discussion. Why? A later step can't rebuild early decisions from the last 2,000 characters. A stopped combo can also leave partial edits, so inspect them before restarting.

In any tool, the handover is evidence. Whatever carries it, the next step still has to look. Always.