What is skeleton-of-thought prompting, and when does parallel expansion hurt quality?

## The pattern Skeleton-of-thought splits long-form generation into an outline phase and an expansion phase. The first call sees the request and returns a skeleton: a short numbered list of section headings or one-line point summaries, deliberately terse. The application then issues one call per skeleton point, each asking for that point expanded to full prose, and concatenates the results in skeleton order. The distinguishing feature is that the expansion calls are independent of one another, so they are issued concurrently rather than in series. That is the opposite of a normal prompt chain, where stage two waits on stage one. ## Why it helps **Wall-clock latency.** Generation is sequential per response: a long answer takes long mainly because tokens come out one after another. Splitting a twelve-section report into twelve concurrent expansions means total time is roughly the outline call plus the slowest section, not the sum of twelve sections. On a long report this is the difference between a minute and a handful of seconds, and it is the pattern's original motivation. **Structural control.** You get to see and, if you like, edit or validate the outline before paying for any expansion. Wrong shape, missing section, or a heading outside the brief can be caught for the cost of one small call. That review point is worth having independently of the latency win. **Length control per section.** A single long generation drifts in section length, front-loading detail and trailing off. Per-section calls with an explicit word budget produce more even coverage. ## What it costs Token cost rises. Each branch re-sends the shared framing, the skeleton, and any source material, so a twelve-way expansion pays that overhead twelve times. A stable prefix can often be cached by the provider, which softens the bill considerably, but the request count and any per-request overhead remain. Concurrency also pushes you against provider rate limits far faster than a single call does, so a fan-out needs bounded parallelism. ## When parallel expansion degrades the output The pattern assumes the sections are independent. Where that assumption fails, the damage shows up in predictable ways. **Interdependent content.** A stepwise mathematical proof, a tutorial where step four uses the file created in step two, or code where later functions call earlier ones cannot be expanded in isolation. Each branch has to guess what its predecessor established, and the guesses do not agree. **Repetition.** Independent branches all reach for the same background. Every section opens by re-explaining the same premise, because no branch knows another already covered it. The concatenated result reads padded even though each section alone reads fine. **Inconsistent commitments.** Branches silently pick different assumptions, terminology, units, or examples. One section says the sample is regional, another treats it as national. Nothing is internally contradictory within a section; the contradiction only exists in the assembled document. **No connective tissue.** Sections cannot reference each other, so transitions are absent or generic, and the whole reads like a stapled set of memos rather than one argument. **Uncontrolled total length.** Each branch decides its own depth, so the assembled output can be several times the length anyone wanted. ## Mitigations Pass the whole skeleton into every expansion call, not just that branch's point. A branch that knows what sections three and five will cover stops re-explaining their material and can defer to them. Add an explicit scope and word budget per section, and state which section owns the shared background so exactly one branch writes it. Where a genuine dependency exists between two points, do not fight it: chain those two sequentially and parallelise only the rest, which is usually most of them. Finally, add a cheap assembly pass over the concatenated draft that removes duplicated background, harmonises terminology, and writes transitions. It is one extra call over material that already exists, it runs on a small model, and it recovers most of what the fan-out lost. That pass is what turns the pattern from a demo into something you would ship. ## When not to reach for it If the answer is short, the outline overhead dominates and there is nothing to parallelise. If the content is inherently sequential, expand in order and accept the latency, or stream the single response so the user sees progress instead. And if perceived latency is the real problem rather than total latency, streaming a single generation is simpler, cheaper, and usually enough.