ClaudeTemplate, 5 blanks to fill

Write a technical blog post with me in stages: outline first, then one section at a time, each approved before the next. Inputs: - Topic or working title: [TOPIC] - Reader and what they already know: [READER] - What the reader should be able to do or understand afterwards: [OUTCOME] - Material to draw on: [SOURCE MATERIAL] - Length: [LENGTH] Steps: 1. Propose an outline: sections and subsections, each with one line on its purpose. Include where a code sample, diagram or worked example belongs. 2. Stop and wait for my approval or changes. 3. Write one section at a time. Explain the reasoning before stating a conclusion, and show a small concrete example before any general rule. 4. Use exact names for tools, versions and commands. If something depends on a version or setting you do not know, say so instead of guessing. 5. After each section, stop and wait. When all sections are approved, assemble the full post with an introduction that states the outcome and a closing section with next steps. Format: - Markdown with headings, code blocks with the language named, and short paragraphs. - No claims about benchmarks, adoption or performance unless they appear in my source material. Quality check: For each code block, state what it assumes is installed or configured.

The words in brackets are the parts you replace with your own details.

Claude

Technical blog post, section by section prompt

Use this for engineering blogs, tutorials and write-ups where accuracy matters more than speed. Claude proposes an outline, waits for your edits, then writes each section separately so you can correct a wrong detail before it spreads through the rest of the post. It explains before concluding, uses exact tool names and versions, and states what every code sample assumes, which is where most technical posts trip up their readers. Bring your own notes or code and it builds the post around them, keeping your terminology and your examples instead of generic ones.

ClaudeOpen Claude

Replace [TOPIC] and [READER] and [OUTCOME] and [SOURCE MATERIAL] and [LENGTH] with your own text before you send it.

Writing

Adapted from a prompt by turhancan97 on prompts.chat (CC0-1.0), rewritten as a template by us.

More inspiration

Open in Claude Write your own

What each part of the prompt does

Approval gates: Stopping after the outline and after each section keeps you in control. Catching a wrong premise in section two is cheap; catching it in a finished post means rewriting.
Example before rule: Readers of technical posts follow a small concrete case more easily than an abstract principle. Step 3 puts the example first and the generalisation after.
Admit unknown versions: Commands and config change between releases. Asking Claude to say when it does not know a version prevents confident instructions that only worked two releases ago.
Code assumptions: Listing what each code block expects to be installed or configured answers the most common comment on any tutorial: it did not work for me.

Variations to try

Same idea, one thing changed.

Write it all at once
Write a technical blog post: show the outline first, then the full post in the same reply. Inputs: - Topic or working title: [TOPIC] - Reader and what they already know: [READER] - What the reader should be able to do or understand afterwards: [OUTCOME] - Material to draw on: [SOURCE MATERIAL] - Length: [LENGTH] Steps: 1. Propose an outline: sections and subsections, each with one line on its purpose. Include where a code sample, diagram or worked example belongs. 2. Continue straight to the writing. 3. Write one section at a time. Explain the reasoning before stating a conclusion, and show a small concrete example before any general rule. 4. Use exact names for tools, versions and commands. If something depends on a version or setting you do not know, say so instead of guessing. 5. Assemble the full post with an introduction that states the outcome and a closing section with next steps. Format: - Markdown with headings, code blocks with the language named, and short paragraphs. - No claims about benchmarks, adoption or performance unless they appear in my source material. Quality check: For each code block, state what it assumes is installed or configured.
From a conference talk
Write a technical blog post with me in stages: outline first, then one section at a time, each approved before the next. Inputs: - Topic or working title: [TOPIC] - Reader and what they already know: [READER] - What the reader should be able to do or understand afterwards: [OUTCOME] - Material to draw on: [SOURCE MATERIAL] (a talk transcript and slides; turn spoken asides into written explanation and drop audience jokes) - Length: [LENGTH] Steps: 1. Propose an outline: sections and subsections, each with one line on its purpose. Include where a code sample, diagram or worked example belongs. 2. Stop and wait for my approval or changes. 3. Write one section at a time. Explain the reasoning before stating a conclusion, and show a small concrete example before any general rule. 4. Use exact names for tools, versions and commands. If something depends on a version or setting you do not know, say so instead of guessing. 5. After each section, stop and wait. When all sections are approved, assemble the full post with an introduction that states the outcome and a closing section with next steps. Format: - Markdown with headings, code blocks with the language named, and short paragraphs. - No claims about benchmarks, adoption or performance unless they appear in my source material. Quality check: For each code block, state what it assumes is installed or configured.

If the result isn't right

Paste real code from your project into [SOURCE MATERIAL]; posts built on working code need far less checking.
Run every command in the draft on a clean machine or container before publishing.
If a section gets long, ask Claude to split it into subsections and approve them one by one.
Keep the approved outline; it doubles as the summary for social posts and the meta description.