How to Use Claude for Writing

Claude excels at writing tasks because of its ability to follow nuanced instructions about tone, structure, and audience. The secret to getting great writing from Claude is the system prompt. Unlike a single user message, a system prompt sets persistent instructions that shape every response in the conversation. For example, setting a system prompt like "You are a senior technical writer. Write in active voice, keep sentences under 20 words, avoid jargon unless defining it first, and target a developer audience with 2-5 years of experience" produces dramatically different output than a bare request to "write an article."

For editing workflows, Claude works best when you give it a clear role and specific editing criteria. Instead of "make this better," try "edit this draft for clarity and conciseness. Remove filler words, break long paragraphs into shorter ones, and flag any claims that need citations." You can also use Claude as a writing partner by asking it to outline first, then expand section by section. This approach gives you control over structure while letting Claude handle the prose. For longer pieces, feed Claude your outline and ask it to draft one section at a time, referencing previous sections for consistency.

Claude is particularly strong at adapting to different writing styles. Provide a sample of your existing writing and ask it to match that voice. It handles formal reports, conversational blog posts, marketing copy, and technical documentation equally well when properly prompted. Save your best system prompts and writing instructions in a prompt library so you can reuse them across projects without rewriting your preferences each time.

Copy-Ready Claude Writing Prompts

Writing prompts optimized for Claude's nuanced instruction-following. Copy, fill in your details, and write.

Long-Form Article

Write a comprehensive article on {{topic}} for {{publication_type}}.

**Audience:** {{target_audience}}
**Word count:** {{word_count}} words
**Tone:** {{tone}} (e.g., authoritative but accessible, conversational, academic)

Structure:
1. Hook — Open with a compelling anecdote, surprising statistic, or provocative question
2. Context — Why this topic matters right now
3. Main argument — {{main_thesis}} supported by evidence and examples
4. Counterarguments — Address the strongest objection honestly
5. Practical takeaways — What the reader should do with this information
6. Closing — Circle back to the opening hook with a new perspective

Writing rules:
- Active voice, concrete nouns, strong verbs
- One idea per paragraph
- Use subheadings every 200-300 words
- Include at least 2 specific examples or case studies
- No filler phrases ("In today's fast-paced world", "It's important to note")
topicpublication_typetarget_audienceword_counttonemain_thesis

Why it works: The explicit structure with a hook-to-closing arc gives Claude a roadmap instead of generating meandering prose. Banning filler phrases and requiring specific examples forces substantive writing over generic content.

Editing Pass

Edit the following draft for {{editing_focus}}:

---
{{draft_text}}
---

Editing instructions:
1. **Clarity** — Rewrite any sentence that requires more than one read to understand
2. **Conciseness** — Cut filler words, redundant phrases, and unnecessary qualifiers. Target a {{percentage}}% reduction in word count
3. **Flow** — Ensure each paragraph transitions logically to the next
4. **Voice** — Maintain the author's voice — do not make it sound like AI wrote it
5. **Fact flags** — Mark any claims that should be verified with [VERIFY: reason]

Return the edited version with:
- Track-changes style: show deletions in ~~strikethrough~~ and additions in **bold**
- A summary of the top 5 most impactful changes you made and why
- One suggestion for structural reorganization (if applicable)
editing_focusdraft_textpercentage

Why it works: Separating editing into specific dimensions (clarity, conciseness, flow, voice) produces targeted improvements instead of a vague "rewrite." The track-changes format lets the author see exactly what changed and accept or reject each edit.

Style Matching

Here is a sample of writing whose style I want you to match:

---
{{writing_sample}}
---

Analyze this writing style along these dimensions:
- Sentence length and rhythm (short/punchy, long/flowing, mixed)
- Vocabulary level (simple, technical, literary)
- Use of metaphor and figurative language
- Paragraph structure and length
- How the author handles transitions
- Distinctive quirks or patterns

Now write {{content_description}} in this exact style. The topic is {{topic}}.

Important: Match the STYLE, not the content or opinions. The new piece should sound like the same author wrote it but on a completely different subject.
writing_samplecontent_descriptiontopic

Why it works: Asking Claude to analyze the style dimensions first — then write — produces much better mimicry than just saying "write like this." The explicit separation of style from content prevents Claude from parroting the sample's ideas.

Research Synthesis

I have research from multiple sources on {{research_topic}}. Synthesize them into a coherent narrative.

**Source 1:** {{source_1_summary}}
**Source 2:** {{source_2_summary}}
**Source 3:** {{source_3_summary}}
{{additional_sources}}

Write a {{output_type}} that:
1. Identifies the key themes that appear across multiple sources
2. Notes where sources agree and where they contradict each other
3. Highlights the strongest evidence and most compelling arguments from any source
4. Identifies gaps — what questions do these sources leave unanswered?
5. Synthesizes a balanced conclusion that accounts for the full evidence base

Do NOT just summarize each source sequentially. Organize by theme, weaving sources together. Cite sources by number (Source 1, Source 2, etc.) inline.
research_topicsource_1_summarysource_2_summarysource_3_summaryadditional_sourcesoutput_type

Why it works: The instruction to organize by theme instead of sequentially is critical — it forces Claude to actually synthesize rather than produce a series of summaries. Asking for contradictions and gaps produces an honest analysis, not just a positive summary.

Creative Fiction

Write a {{fiction_type}} ({{word_count}} words) with these elements:

**Setting:** {{setting}}
**Main character:** {{character_description}}
**Central conflict:** {{conflict}}
**Tone/mood:** {{tone}}
**Theme (subtle, not stated):** {{theme}}

Writing guidelines:
- Show, don't tell — convey emotion through action and dialogue, not narration
- Open in media res — start in the middle of something happening
- Use sensory details (at least 3 senses per scene)
- Dialogue should reveal character — each person should sound distinct
- End with resonance, not resolution — leave the reader thinking
- No cliches: avoid "a chill ran down their spine," "little did they know," "the silence was deafening"

Write the complete piece, not an outline or a first chapter.
fiction_typeword_countsettingcharacter_descriptionconflicttonetheme

Why it works: Banning specific cliches and requiring sensory details produces prose that reads as crafted rather than generated. The "resonance not resolution" ending instruction prevents the generic wrap-up that makes AI fiction feel formulaic.

Technical Documentation

Write technical documentation for {{subject}} targeting {{audience_level}} developers.

**What it does:** {{description}}
**Key concepts they need to understand:** {{concepts}}

Document structure:
1. **Quick Start** — Get something working in under 5 minutes (show the minimal viable example)
2. **Core Concepts** — Explain the mental model. Use diagrams described in text if helpful
3. **API Reference** — Every public method/endpoint with parameters, return values, and examples
4. **Common Patterns** — The 3-5 most common use cases with complete code examples
5. **Troubleshooting** — The 5 most common errors and how to fix them
6. **Migration Guide** — If upgrading from {{previous_version}}, what changed and how to update

Writing rules:
- Lead with code, follow with explanation (developers read code first)
- Every code example must be complete and runnable — no "..." or "// add your code here"
- Use second person ("you") not third person ("the developer")
- Keep sentences under 25 words
- Bold key terms on first use
subjectaudience_leveldescriptionconceptsprevious_version

Why it works: The "lead with code, follow with explanation" rule matches how developers actually read docs. Requiring complete, runnable examples prevents the frustrating experience of docs with incomplete snippets that don't actually work.