Long Form Polish

---
name: long-form-polish
description: >-
  Polish a long-form technical draft for pacing, scan-ability, and tightness.
  Cover paragraph and sentence rhythm, the scan reader's experience (headings,
  callouts, pull quotes, white space, lists, tables), the 30% cut discipline
  for removing filler, and the read-aloud test for finding bumps. Distinct
  from short-form line-level editing — this skill works at the paragraph
  and section level for pieces of 1500-5000+ words. Use when the user asks
  to polish a long article, fix pacing, improve scan-ability, run a cut pass,
  do a read-aloud test, tighten a draft, fix uneven sections, or prepare a
  draft for publication. NOT for short-form clarity editing of memos / RFCs /
  emails (use communication/clarity-editing). NOT for sentence-level craft
  techniques like AIDA / PAS (use engaging-craft). NOT for outlining or
  structural changes (use long-form-structure). NOT for code documentation
  cleanup (use documentation-generator).
---

# Long-form Polish

> Polish is what separates a draft a reader can finish from a draft that *anyone* can finish. Most long-form pieces fail in the polish phase, not the drafting phase — the substance is there but the experience of reading it is friction-heavy.

This skill covers paragraph- and section-level polish: pacing, scan-ability, the cut, the read-aloud test. It's distinct from line-level clarity editing (which works on individual sentences for active voice, hedge removal, jargon strip — that's communication/clarity-editing's job). Long-form polish is about how the *whole* reads.

## Core principle

**Polish for the skim reader without abandoning the deep reader.** A 3000-word piece is read by two readers at once: the skimmer scanning headings and bold text in 90 seconds, and the careful reader committing 12 minutes. Both need to leave with value. Polish is the discipline of serving both.

## Pacing and rhythm

Pacing is how the prose feels in time. Drafted prose tends to be monotone — same sentence length, same paragraph length, same energy throughout. Polished prose varies deliberately.

### Sentence length variation

| Pattern | Effect |
|---|---|
| Long, long, long | Slows the reader; appropriate for absorbing complex models |
| Short, short, short | Accelerates; appropriate for delivering payoffs and emphasis |
| Long, short | Long sentence builds; short sentence punches |
| Short, long | Short sentence sets up; long sentence develops |

The reliable polish move: find sequences of three or more sentences with similar length. Break the pattern by inserting a sentence of contrasting length.

```
Drafted (monotone):
"The migration was painful for several reasons. The schema change required updating multiple
 services. The data backfill took over a week. The team had to coordinate with downstream
 consumers."

Polished (varied):
"The migration was painful — three reasons. The schema change cascaded through eight services.
 The backfill took nine days. And every downstream consumer needed coordination, which meant
 daily syncs with three teams.

 It was tedious."
```

The varied version is less words but more presence. The two-word sentence ("It was tedious.") punches because the surrounding sentences set it up.

### Paragraph length variation

Paragraphs work the same way. A page of identical-length paragraphs reads flat; varied lengths breathe.

| Length | Use |
|---|---|
| One sentence | Punch. Emphasis. Pivot. |
| 2-3 sentences | Workhorse paragraph. Most prose lives here. |
| 4-5 sentences | Developing an idea; technical setup. |
| 6+ sentences | Complex argument; rare; risks losing the skim reader. |

Avoid the 200-word paragraph wall. The reader's eye sees a wall and bounces.

### Section length variation

Sections within a long article should also vary. A 3000-word piece with six 500-word sections is monotonous; one with sections of 200 / 600 / 800 / 400 / 700 / 300 reads as deliberately paced.

The reliable check: tally each section's word count. Variance is good. Uniformity is suspicious.

See `references/pacing-and-rhythm.md` for the full pacing toolbox and worked examples.

## Scan-ability

The skim reader scans:

1. The title and dek.
2. Section headings (H2s).
3. The first sentence of each paragraph.
4. Bold text within paragraphs.
5. Lists, tables, and callouts.
6. Closing paragraph.

A piece optimized for scan-ability lets the skim reader leave with the article's main points in 90 seconds. A piece that ignores scan-ability requires linear reading or the skimmer leaves with nothing.

### Scan-ability moves

| Move | Purpose |
|---|---|
| Section headings every 200-500 words | The skimmer's table of contents |
| Sub-headings (H3) when sections have parts | Hierarchy without long sections |
| Topic sentences first | First-sentence-of-paragraph carries the meaning |
| Bold key claims sparingly | Highlight the load-bearing assertion |
| Tables for comparisons | Structured data scans faster than prose |
| Lists for enumerable items | Parallel structure aids scanning |
| Callout boxes for tangents | Removes interrupters from the main flow |
| Pull quotes for memorable lines | Visual anchors; quotable content |

See `references/scannability.md` for the complete scan-ability toolkit and the skim-reader audit.

### Scan-ability anti-patterns

- **Long unbroken sections** (1000+ words without a heading).
- **Topic sentences buried** (first sentence of paragraph is throat-clearing; the actual point is sentence 4).
- **Bold inflation** (everything is bold; nothing stands out).
- **Lists for everything** (three-item lists where prose would carry better).
- **Headings that don't preview content** ("Some thoughts" doesn't tell the skimmer what's there).

## The 30% cut

Every drafted long-form piece can lose 20-40% without changing its meaning. Cut for tightness; the reader feels the difference.

### What to cut

| Category | Examples |
|---|---|
| **Hedges** | "It might be worth considering whether perhaps" → "Consider" |
| **Throat-clearing** | "Now we'll discuss…" → start with the discussion |
| **Recap padding** | "As we saw in the previous section…" → trust the reader |
| **Filler transitions** | "It's important to note that…" → just note it |
| **Redundant adjectives** | "comprehensive, robust, scalable solution" → name the specific quality |
| **Self-conscious meta** | "I'm aware this is a complex topic, but" → just write it |
| **The "in this article we will" preface** | Cut entirely; let the title and hook do the work |
| **Restated points** | A point made twice in the same section; cut one |
| **Generic examples** | Swap for specific ones (and if no specific exists, cut) |
| **Defensive overqualification** | "of course there are exceptions, this isn't always true, you know your context best, but" → trust the reader |

### What not to cut

| Category | Why keep |
|---|---|
| Concrete examples | These are the article's substance |
| Citations | Load-bearing for credibility |
| Voice markers | Personality is hard-won; preserve it |
| Specific numbers and names | The article's grip |
| Genuine qualifications | Real "unless" / "except when" / "limited to" |
| Counter-arguments addressed | Earned credibility |

### The cut in three passes

1. **Pass 1: hedge and filler removal.** Quick. Cut every "I think," "perhaps," "it seems," "in some sense," "kind of," "sort of," "really" that doesn't earn its position.
2. **Pass 2: throat-clearing and meta.** Cut every "in this section," "as we discussed," "now let's look at." The reader can see structure from the headings.
3. **Pass 3: redundancy.** Sentences that say what previous sentences already said. Paragraphs that recap rather than develop. Cut.

After three passes, the draft is typically 30% shorter and reads twice as fast.

See `references/cut-discipline.md` for full cut protocols and examples of well-cut prose.

## The read-aloud test

The single most reliable polish technique. Read the draft aloud, paying attention to where you stumble.

### What you find

| Stumble | What it means |
|---|---|
| Tongue-twisters | Awkward consonant combinations; word order to fix |
| Run-on sentences | Need to break |
| Run-out-of-breath sentences | Same; needs breaks |
| Sentences you can't parse aloud | Reader can't parse silently either |
| Sentences with no rhythm | Add or remove syllables until they sing |
| Flat paragraphs | Need a punch sentence |
| "Wait, what?" moments | Logic break or unstated transition |

### Why it works

Reading silently lets the reader's brain auto-correct. Reading aloud forces the prose to actually work syllable by syllable. Bumps become audible.

### Practical approach

1. Read aloud, slowly.
2. Mark every stumble with a margin note.
3. After the read-through, fix each marked stumble.
4. Re-read the fixed passages aloud.
5. Iterate until the read is smooth.

A 3000-word piece takes 25-40 minutes to read aloud. The polish gain is enormous.

See `references/read-aloud-test.md` for the full protocol, what to do about specific stumble types, and when to delegate the read-aloud to a tool.

## ✅ Use for

- Polishing a long-form draft before publication
- Fixing pacing problems (monotone sentences, monotone paragraphs)
- Improving scan-ability (the skim reader experience)
- Running a 30% cut pass on a bloated draft
- Doing a read-aloud test on a piece
- Tightening a draft that "feels long"
- Equalizing pacing across uneven sections
- Adding callouts, pull quotes, and visual hierarchy

## ❌ NOT for

- **Short-form clarity editing** (RFCs, memos, emails) — use communication/clarity-editing
- **Sentence-level craft techniques** (AIDA, PAS, hooks, voice calibration) — use engaging-craft
- **Outlining or structural changes** — use long-form-structure
- **Code documentation cleanup** — use documentation-generator
- **UI microcopy** — use ux-writing
- **Pre-writing research / sourcing** — use technical-research

## Anti-patterns

### The polish bypass

**What it looks like:** "It's done — let me just publish." The draft goes live without a polish pass.

**Why it's wrong:** Drafted prose is *first-pass* prose. It carries the writer's thinking-out-loud, the half-finished sentences they meant to fix, the hedges they forgot to cut. The reader gets the cost.

**What to do instead:** Treat polish as a non-negotiable phase. Budget 30-60 minutes per 1000 words for polish. The piece nearly always improves dramatically.

### The infinite polish

**What it looks like:** Eight polish passes, each making smaller changes. The piece stays in editorial purgatory.

**Why it's wrong:** After 2-3 polish passes, you're rearranging deck chairs. The piece is done; ship it.

**What to do instead:** Limit polish to 2-3 passes. After that, ship and let real readers reveal the next round of improvements.

### Over-bolding

**What it looks like:** Every other sentence has a bold phrase. The page looks like a highlighter exploded.

**Why it's wrong:** When everything is emphasized, nothing is. The reader's eye stops noticing the bold.

**What to do instead:** Bold sparingly — 1-2 phrases per major section, marking the load-bearing claim. Use other tools (lists, tables, callouts) for visual variety.

### Over-listification

**What it looks like:** Three-item lists where prose would carry better. Lists nested inside lists. Lists of one-word items.

**Why it's wrong:** Lists fragment continuous reasoning. A list of "X, Y, Z" reads as parallel options when the actual claim is "X because Y, which leads to Z."

**What to do instead:** Use lists when items are genuinely parallel (steps, options, items). Use prose when items have logical relationships among themselves.

### The "improvement" that's just rewording

**What it looks like:** Polishing pass that swaps "utilize" for "use" but doesn't actually change the prose's clarity, pacing, or scan-ability.

**Why it's wrong:** Cosmetic rewording isn't polish; it's rearranging. The reader gets no benefit.

**What to do instead:** Polish must change something the reader experiences. Cut a hedge, vary a sentence length, break a long paragraph, surface a buried point. If the change isn't perceptible to a reader, skip it.

### Polish without re-reading

**What it looks like:** A flurry of edits, then publishing. No final read-through.

**Why it's wrong:** Polish edits frequently *introduce* new bumps (broken transitions, inconsistent tense, leftover words from a half-revised sentence). Without a re-read, those ship.

**What to do instead:** After polishing, re-read the piece end-to-end one more time. Fix what you find. Then ship.

### Polish that drifts the voice

**What it looks like:** A conversational draft polished into "professional" prose. The reader notices the voice change.

**Why it's wrong:** Polish should *clarify* the voice, not change it. A piece that started colloquial and ended formal feels like the writer was insecure about the original voice.

**What to do instead:** Decide on the voice (see engaging-craft/references/voice-and-tonality.md). Polish toward the voice you committed to.

## Workflow

1. **Confirm the draft is structurally complete.** If sections are missing or out of order, fix structure first (long-form-structure). Polish doesn't fix structure problems.
2. **Cut pass 1 — hedges and filler.** Fast. Removes ~10%.
3. **Cut pass 2 — throat-clearing and meta.** Fast. Removes another ~10%.
4. **Cut pass 3 — redundancy.** Slower. Removes ~10-20%.
5. **Pacing pass — sentence length variation.** Find monotone sequences; vary.
6. **Pacing pass — paragraph length variation.** Break walls; insert short paragraphs at pivots.
7. **Scan-ability pass.** Audit headings, topic sentences, bold usage, list usage, callouts.
8. **Read-aloud pass.** Mark stumbles; fix; re-read marked passages.
9. **Final end-to-end read.** Catch anything the polish passes broke.
10. **Hand off to distribution-craft** for title, dek, social pulls.

## References

| File | Contents |
|---|---|
| `references/pacing-and-rhythm.md` | Sentence and paragraph rhythm; the variation toolbox; common pacing failures |
| `references/scannability.md` | The skim reader's experience; headings, callouts, lists, tables; visual hierarchy audit |
| `references/cut-discipline.md` | The 30% cut; three-pass cut protocol; what to keep, what to lose; example transformations |
| `references/read-aloud-test.md` | The read-aloud protocol; what stumbles mean; how to revise; when to use TTS |

## Related skills

- **long-form-structure** — fix structural problems before polishing.
- **engaging-craft** — sentence-level craft techniques (AIDA, PAS, hooks, voice).
- **technical-research** — load-bearing claims should already be sourced before polish.
- **distribution-craft** — title, dek, social pull-quotes after the body is polished.
- **communication/clarity-editing** (skillstack) — line-level editing for short-form work writing.
- **storytelling** (skillstack) — narrative pacing for non-technical pieces.