Use when a form is already the right length but the order and the step breaks are losing people.
multi-step-form-step-sequencing.md
You are sequencing a multi step form. You are not deciding which fields exist, only what order they appear in and where the step breaks fall.
FIELDS ALREADY AGREED: {{FIELD_LIST}}
WHAT THE VISITOR CAME TO DO: {{VISITOR_GOAL}}
DROP-OFF BY CURRENT STEP IF KNOWN: {{STEP_DROPOFF}}
WHAT WE CAN DO WITH A PARTIAL SUBMISSION: {{PARTIAL_VALUE}}
Produce:
1. A table: Step | Fields on it | Why these belong together | Effort felt by the visitor (Low/Med/High) | What the visitor gets for finishing this step.
2. The reason for each step break: it exists to lower perceived effort, to save a partial record, or to branch on an earlier answer. A break with none of those three reasons should be removed, and say so.
3. Which fields from {{FIELD_LIST}} must sit on step one for {{PARTIAL_VALUE}} to be usable, and which must not sit there because they raise commitment too early.
4. The progress indicator: how many steps to show, whether to number them, and what to label the final button.
5. Two alternative sequences worth testing against this one, each with the behaviour it assumes.
Constraints: do not recommend more steps than the field count justifies, and never split a form purely to make each step look short. Where {{STEP_DROPOFF}} is missing, mark every ordering claim as heuristic. Judge step one against {{VISITOR_GOAL}}: if it asks for something before the visitor sees any progress toward that goal, flag it. No em dashes.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When do I sequence rather than cut fields?
When the field list is already agreed and the losses are happening at the step breaks rather than because the form is long. Cut first with the field reduction prompt, then sequence what survives. This one explicitly refuses to decide which fields exist, so running it on an unpruned form just orders too many questions neatly.
What do I need in front of me before running it?
The agreed field list, what the visitor came to do, drop-off by current step, and what you can genuinely do with a partial submission. Partial value drives which fields have to sit on step one. Where step drop-off is missing every ordering claim comes back marked heuristic, which is honest but much less useful.
What comes back, and which part is worth acting on?
A step table, the reason each break exists, which fields must and must not sit on step one, progress indicator guidance and two alternative sequences to test. The reason column is the real test: a break that does not lower perceived effort, save a partial record or branch on an answer is marked for removal.
What is the mistake that costs me here?
Splitting the form so each step looks short. That is the failure mode the prompt names, and it adds clicks without removing effort. The second one is arguing about sequencing while the partial record is still saved at the end, because nothing you decide about step one matters until that submit stores something usable.