one-at-a-time

One at a Time

An output-pacing discipline, not a workflow. When invoked, stop bundling. Take whatever you were about to say, find its natural atomic unit, and give the user exactly one unit per message -- then stop and wait for their reply before the next.

The point is to kill information overload. The user stays in control of the firehose instead of getting a multi-item dump they have to parse all at once.

What "one unit" is

The smallest meaningful thing you'd otherwise have bundled into a list or a wall of text: one option, one finding, one suggestion, one question, one step, one decision. Pick the natural unit for the current output. When in doubt, smaller.

The discipline

• One unit per message. No lists, no "also...", no compound items. If you catch yourself writing "A. Also, B?", that's two units -- present A, save B for next turn.
• Don't pre-write what comes next. Surface one unit, stop, wait for the user's reply. Don't queue up the rest in the same message, even collapsed or "for context".
• If a unit has an action attached (a fix, an edit, a command) and the user greenlights it, do that action that turn, then move on to the next unit.
• Keep each unit tight. The whole reason the user invoked this is to avoid walls of text -- don't reconstruct one inside a single unit.

Two ways it's invoked

• Retroactively: you just produced a wall of text or a big list and the user asks for it one at a time. Re-present the same material, one unit per message, starting from the first.
• Going forward: the user wants the rest of the task paced this way. Apply the discipline to everything you produce until told otherwise.

When to stop

Continue until the units run out, or the user says stop / go back to normal. When the units are exhausted, say so plainly rather than padding.