Verified against ChatGPT · 2026-08-14
Map a manuscript's pacing scene by scene so slow stretches show up as data, not just a feeling
Produces a scene-by-scene table tracking tension level, new information, and page length so pacing problems become visible as patterns in the numbers rather than a vague sense that a section 'drags.'
The prompt
Ready to copy — highlighted parts are example details you can swap.
Do a pacing audit of the manuscript excerpt below, scene by scene. I don't want a general impression of whether it drags — I want the actual pattern made visible so I can see exactly where and why.
MANUSCRIPT EXCERPT (broken into scenes if not already)
[Pasted chapters 4-6 of a novel manuscript, roughly 6,000 words, with scene breaks marked]
GENRE AND EXPECTED PACE
Thriller, expected to maintain forward tension with no more than one genuinely quiet breather scene per three chapters.
WHERE THE AUTHOR FEELS IT DRAGS
I think chapter 5 drags because of the long flashback in the middle of it.
RULES
Break the excerpt into its constituent scenes (or use the breaks already present) and, for each one, assess three things: a tension rating from 1-10 relative to the scene immediately before it (not an absolute score, since the same tension level reads differently depending on what preceded it), what new information or stakes-change the scene delivers to the reader (state it in one phrase, or state explicitly if none), and the scene's approximate length relative to how much new information it delivers, flagging a mismatch (a long scene delivering little new, or a critical beat rushed through in a few lines). After scoring every scene, identify the actual pattern: consecutive scenes with flat or declining tension and no new information are the real signature of a pacing problem, not any single scene's individual score — call out specific runs of scenes where this occurs by scene number. Directly address I think chapter 5 drags because of the long flashback in the middle of it.: confirm whether the data supports the author's instinct, and if the problem is somewhere else in the pattern instead, say so plainly rather than agreeing with the stated suspicion by default.
WHAT NOT TO DO
Do not give a single overall pacing verdict for the whole excerpt ("the pacing is generally fine" or "the pacing drags overall") without the scene-by-scene data to support exactly where — a global verdict without the underlying pattern isn't actionable. Do not suggest specific rewritten prose in this pass; the deliverable is diagnostic, not a rewrite — recommend what kind of fix a slow run needs (cut, compress, add stakes) without drafting the fix itself.
OUTPUT FORMAT
1. A table: Scene # | Relative Tension (1-10) | New Info/Stakes Delivered | Length vs. Info Mismatch (flag if any).
2. A short list of specific scene-number runs that show the flat-tension, no-new-information pattern.
3. A direct verdict on I think chapter 5 drags because of the long flashback in the middle of it., confirming or redirecting based on the data.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Pacing problems are notoriously hard to self-diagnose because "this section drags" is a felt impression, not a located cause, and a model asked for general pacing feedback will tend to produce an equally impressionistic response — a paragraph confirming the vague feeling back to the writer without the underlying evidence, since impression-level feedback is easier to generate than a structured scene-by-scene accounting. Forcing a per-scene tension rating relative to the immediately preceding scene, rather than an absolute score, matters mechanically because pacing is a rate of change, not a static level — a scene rated 6/10 tension reads as a slowdown after a run of 8s and as a rise after a run of 3s, and an absolute scoring scheme would obscure exactly the pattern that constitutes a pacing problem. Requiring the new-information-or-stakes-change field alongside the tension score targets the actual mechanism of a dragging section: tension and plot momentum aren't the same thing, and a scene can maintain surface tension while delivering nothing new to the reader, which is the real signature of a stall even when no individual scene looks obviously weak in isolation. Requiring the model to identify runs of consecutive flat scenes, rather than commenting scene-by-scene without synthesis, is what actually converts the data into a usable diagnosis — a table of forty individual scores without a called-out pattern puts the synthesis work back on the writer, defeating the point of asking for an audit instead of raw notes. Requiring a direct, specific verdict on the author's own suspicion — rather than reflexive agreement — closes the same sycophancy gap relevant to developmental editing generally: a writer's instinct about where a problem lives is frequently pointed at the symptom (a flashback that felt slow to write) rather than the actual cause (a run of low-stakes scenes building up to it), and only a model willing to contradict the stated suspicion with evidence is useful here.
What you get back
Scene 14 (ch.5, the flashback): Tension 3/10 (down from 7 in scene 13). New info: none — restates backstory already established in chapter 2. Length vs. info: mismatch flagged, 900 words for zero new stakes. Pattern: scenes 12-15 show a four-scene flat run with no new information, which is the actual drag — not the flashback itself, but that it lands inside an already-declining stretch.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
