Prompting for writing

1. What's different about writing

Writing prompts are the inverse of code prompts. Code has clear success criteria (it runs); writing has fuzzy ones (it lands). Code has hidden conventions you have to state; writing has hidden voice you have to show.

The shift from code-mode to writing-mode is mostly about leaning on examples instead of constraints.

2. The defaults for writing prompts

• A voice sample. Two or three paragraphs of your existing writing — blog post, PR description, internal memo. The model matches the voice.
• The audience. Who is reading. Engineers? Executives? Customers? The audience determines vocabulary and depth.
• The constraint. Length, tone, format. 250 words. Skeptical. Three paragraphs, no headings.
• What to avoid. Hedge words, jargon, motivational filler, opening cliches.
• The thing to write about. Specific content — bullet points, source notes, a draft you want polished.

Most writing prompts skip the voice sample, then complain the output sounds like a generic chatbot.

3. The pair

Write a release note announcing our new feature. Make it engaging but professional.

The output: generic SaaS marketing prose with bullet points and exclamation points and the word "delighted." Indistinguishable from any other release note on the internet.

Write a release note for the feature described below.

Voice: match these two previous notes from us:

---
We shipped: incremental rebuilds.

If you've worked in our editor before, you've probably noticed that opening a large project takes a few seconds. We don't love that either. Today, that goes away.

Reopening a project now takes the same time as switching between two open files. Under the hood: we cache the parsed AST per file and invalidate only what changed. Worst case is about the same as before. Best case (most cases) is roughly instant.

No flag, no setting. It's just on.
---

We shipped: search across files.

You can finally do cmd-shift-f. We know.

It's basic ripgrep wrapped in our UI, with a result preview pane that does syntax highlighting. Big-repo testing on the Linux kernel: under 300ms for most queries.

Two limits worth knowing: binary files are skipped, and matches inside string templates aren't always highlighted correctly. We'll fix the second one.
---

Constraints:
- Under 250 words.
- No "we're excited to announce."
- No exclamation points.
- One short paragraph for what shipped, one for why it matters, one for the limits.

Feature to announce: [feature description]

The output will match the voice — direct, slightly self-deprecating, specifics-first, no marketing varnish. Because that's what the examples showed.

4. The negative-space move

For writing, what not to do is often clearer than what to do. A short banlist tightens the output more than ten positive instructions.

Common useful bans for engineer-written content:

• No "delve into," "leverage," "in today's fast-paced," "I'm excited to announce."
• No marketing exclamation points.
• No bulleted lists where prose would work.
• No "in conclusion" or "to summarize."

Two minutes of banlist removes a paragraph of stock LLM prose from every output you'll ever generate.

5. Try it