Built a prompt that fixes rambling technical drafts

ZoeDev Intermediate 57m ago 534 views 8 likes 2 min read

Spent years publishing SolidJS tutorials and the feedback loop was brutal — community members kept rewriting my paragraphs because I'd pack six sentences into one block and litter everything with "actually," "simply put," "in fact." Theo from T3.gg once gutted an entire draft just to show me how much dead weight I carried. Grammarly caught typos but couldn't fix structure.

Built a prompt that fixes rambling technical drafts

So I distilled every editing rule I learned into a single prompt. Drop a rough draft in, get back something that respects the reader's attention span.

You are a technical editor for developer tutorials. Rewrite the input following these rules:

1. Paragraphs: maximum 3 sentences each. One idea per paragraph.
2. Cut every filler phrase: "actually," "simply put," "in fact," "honestly," "basically," "just," "really," "literally," "obviously," "clearly," "needless to say," "it goes without saying," "as a matter of fact," "for all intents and purposes."
3. Replace passive constructions with active verbs.
4. Keep code blocks, headings, and technical terms exactly as written.
5. Add blank lines between paragraphs for readability.
6. Do not change the author's voice or technical conclusions — only tighten delivery.
7. Flag any paragraph that still exceeds 3 sentences after editing.

![Built a prompt that fixes rambling technical drafts](/uploads/articles/2077a9cd4f051611.webp)

Return only the edited version.

Tested it on a 1,200-word draft about signals vs observables. Original had 14 paragraphs averaging 5.2 sentences. Output came back at 23 paragraphs averaging 2.1 sentences. The "flag" rule caught two sections I'd missed — both were nested explanations that needed their own headers.

The filler-word list is the real workhorse. Those phrases feel natural while typing but act like speed bumps when reading. Removing them forces you to make the actual point stronger instead of hedging.

Ran it on three team members' RFCs last week. Each came back 18-22% shorter with zero meaning lost. One dev said it felt like "someone finally organized my brain."

Only catch: it won't fix bad architecture or wrong assumptions. But for the mechanical stuff — paragraphing, hedging, passive voice — it's faster than any human review cycle.

webdevPromptdevjournal

All Replies (4)

A
AlexTinkerer Advanced 52m ago
Fails on my kernel driver comments — still unreadable
0 Reply
L
LeoMaker Expert 50m ago
Does it handle code-heavy sections differently than prose?
0 Reply
C
Casey51 Novice 46m ago
@LeoMaker Good question — it treats code blocks as "don't touch" zones and only cleans up the surrounding explanation
0 Reply
C
CameronOwl Expert 48m ago
How does it treat markdown tables in rewrites?
0 Reply

Write a Reply

Markdown supported