20 Claude Prompts for Writing That Sound Like You, Not a Robot

<context> I write for [publication/blog] about [topic area]. My audience is [describe readers]. My writing style is [e.g. conversational but data-driven, technical but accessible, opinionated and direct]. </context> <task> Write a complete blog post based on this outline: [paste your outline] Requirements: - Title and subtitle - Introduction that hooks without being clickbaity - Each section fully developed (not just expanded bullet points) - Conclusion with a clear takeaway or CTA </task> <constraints> - Word count: [target, e.g. 1500-2000 words] - Write in first person if it's a personal blog, third person if it's a company blog - No filler paragraphs that repeat the same point in different words - Every paragraph must earn its place — if I can cut it without losing meaning, it shouldn't be there - Use specific examples, not generic statements </constraints>

<context> Article topic: [topic] Target audience: [who reads this] Article angle: [what makes this piece different from others on the same topic] Tone: [e.g. authoritative, conversational, urgent] </context> <task> Write 3 different introductions for this article (150-200 words each): 1. Story-led: Open with a specific anecdote or scenario 2. Data-led: Open with a surprising statistic or fact 3. Contrarian: Open by challenging a common belief For each, end with a clear thesis statement that sets up the rest of the article. </task> <constraints> - First sentence must hook — no "In today's world" or "Have you ever wondered" - No rhetorical questions as openers (overused) - Be specific — use names, numbers, dates where possible - The reader should know exactly what they'll get from the article by the end of the intro </constraints>

<context> I've done research on [topic] and have rough notes, quotes, and data points. I need this turned into a coherent article. Target publication: [where this will be published] Audience: [who reads this] Word count: [target] </context> <task> Turn these raw notes into a polished article draft: [paste your messy notes, quotes, stats, ideas] Structure it with: - A clear narrative arc (not just notes reorganized into paragraphs) - Smooth transitions between sections - Data and quotes woven naturally into the text (not just listed) - A headline and subheadline </task> <constraints> - Preserve all my original data points and quotes — don't cut them - If a note is unclear, include it with a [CLARIFY: ...] flag rather than guessing - Don't add information I didn't provide — work only with my notes - Maintain the tone of my original notes where it comes through </constraints>

<context> My position: [state your opinion clearly] My credentials on this topic: [why should readers care what you think] The opposing view: [what most people believe or what the status quo is] Publication: [where this will appear] </context> <task> Write an opinion piece (800-1200 words) that: 1. Opens with the strongest version of my argument 2. Acknowledges the best counterargument (steel-man it, don't strawman it) 3. Explains why my position is still correct despite the counterargument 4. Ends with a clear call to action or prediction </task> <constraints> - Be confident, not aggressive — persuade, don't preach - Include at least one concrete example or data point per section - Don't hedge with "I think" or "in my opinion" — the reader knows it's your opinion - The counterargument section must be genuinely fair (this builds credibility) </constraints>

<task> Edit this text for clarity and conciseness. Cut every word that doesn't earn its place: [paste your text] </task> <constraints> - Target: reduce word count by 20-30% without losing meaning - Eliminate: passive voice, filler words, redundant phrases, throat-clearing sentences - Replace vague language with specific language - Keep my voice and tone — tighten, don't rewrite - Flag any sentences where cutting would lose meaning (don't cut those) </constraints> <format> Return the edited version first. Then a "Changes Made" section listing the most significant edits with brief reasoning. </format>

<context> Original tone: [e.g. formal, academic, corporate] Target tone: [e.g. conversational, witty, authoritative] Audience: [who will read the rewritten version] Purpose: [why the tone needs to change — e.g. repurposing for a different channel] </context> <task> Rewrite this text in the target tone: [paste text] </task> <constraints> - Preserve all factual content and key points - Change the HOW, not the WHAT - If the original has data or quotes, keep them but adjust how they're introduced - The rewrite should feel native to the target tone — not like a formal text with casual words swapped in - Match the reading level of the target audience </constraints>

<task> Review this text as a rigorous editor: [paste text] For each claim or argument, evaluate: 1. Is this claim supported? (flag unsupported assertions) 2. Is the logic sound? (flag logical fallacies) 3. Are there stronger examples or evidence I could use? 4. What's the strongest counterargument a skeptical reader would raise? </task> <constraints> - Be brutally honest — I need to know where my arguments are weak - Don't flag opinions as unsupported claims (distinguish between claims of fact and perspective) - For each flagged issue, suggest a specific fix (not just "needs more evidence") - Rate overall argument strength: Strong / Moderate / Needs Work </constraints> <format> Go through the text paragraph by paragraph. For each, either mark "✓ Solid" or flag specific issues. End with an overall assessment. </format>

<context> Original audience: [e.g. technical developers] Target audience: [e.g. non-technical executives] Original content purpose: [e.g. technical documentation] New purpose: [e.g. executive summary for budget approval] </context> <task> Rewrite this content for the target audience: [paste content] Adjustments needed: 1. Replace jargon with plain language (but don't oversimplify) 2. Lead with business impact, not technical details 3. Add context that the new audience needs but the original audience didn't 4. Remove details the new audience doesn't need </task> <constraints> - Don't patronize the new audience — simple doesn't mean dumbed-down - Keep accuracy — if simplifying would create a misunderstanding, keep the precise language and explain it - Maintain the original conclusions and recommendations - Adjust length to match what the new audience expects (execs want shorter) </constraints>

<context> Genre: [e.g. literary fiction, sci-fi, thriller, comedy] Tone: [e.g. dark, whimsical, tense, reflective] Word count: [target] Inspiration: [any authors or stories you want it to feel like] </context> <task> Write a short story based on this premise: [describe your premise — character, situation, conflict] </task> <constraints> - Show, don't tell — use action and dialogue to reveal character - Start in media res (in the middle of the action, not with backstory) - One clear conflict or tension that drives the story forward - End with a resonant closing image or line (not a twist for twist's sake) - No clichés: no "little did they know," no "it was a dark and stormy night" </constraints>

<task> Create a detailed character profile for a [genre] story: Starting point: [name, basic concept, or role in the story] Build out: 1. Physical description (specific details, not generic) 2. Voice — write 5 lines of dialogue that show how they speak 3. Backstory — the ONE event that shaped who they are 4. Motivation — what they want and what they're afraid of 5. Contradiction — the trait that makes them feel real (e.g. a brave person who's afraid of commitment) 6. How they change by the end of the story </task> <constraints> - No character who's "ordinary until something extraordinary happens" — give them something specific from the start - The contradiction should create internal conflict, not just be a quirky trait - Dialogue should be distinctive — I should be able to identify the character by their lines alone - Backstory should be one paragraph, not a biography </constraints>

<context> Genre: [genre] Characters in scene: - [Character A]: [brief description, personality, current emotional state] - [Character B]: [brief description, personality, current emotional state] Setting: [where and when] What's at stake: [what does each character want from this conversation] </context> <task> Write a dialogue-driven scene (500-800 words) between these characters. The subtext: [what's being communicated beneath the words — the unspoken tension] </task> <constraints> - Each character should have a distinct voice (different vocabulary, sentence length, patterns) - Include minimal but purposeful action beats between dialogue (no "he said, adjusting his collar" filler) - The scene must advance the plot or reveal character — not just be clever banter - Subtext > text: the most important thing should be what ISN'T said - No dialogue tags beyond "said" and "asked" (let the dialogue do the work) </constraints>

<context> Genre: [e.g. fantasy, sci-fi, dystopian, alternate history] Story scope: [short story, novel, series] Core premise: [the one thing that makes this world different from ours] </context> <task> Build out this world with: 1. The Rules — How does the core premise change everyday life? (3-5 specific consequences) 2. The Society — How have people organized around these rules? (government, economy, social norms) 3. The Conflict — What tension does this world create? (who benefits, who suffers) 4. The Details — 5 specific, vivid details that make this world feel lived-in (not big concepts — small things) 5. The Vocabulary — 5-10 terms or slang unique to this world with definitions </task> <constraints> - Internal consistency is non-negotiable — no rule should contradict another - The "small details" section is the most important — these make worlds feel real - Every element should create story opportunities (not just be cool worldbuilding) - Avoid common tropes unless you're subverting them </constraints>

<context> Topic: [what the guide teaches] Audience skill level: [beginner / intermediate / advanced] Prerequisites: [what the reader needs before starting] Tool/platform: [what they'll be working with] </context> <task> Write a step-by-step how-to guide that takes the reader from [starting point] to [end result]. Include: 1. What they'll build/achieve (with a screenshot concept or description) 2. Prerequisites checklist 3. Numbered steps with clear instructions 4. Expected output after each major step 5. Troubleshooting section for common issues </task> <constraints> - Each step should be ONE action (not "install X, configure Y, and restart Z") - Include the exact command, code, or UI path — no "configure as needed" - Show expected output so readers know they're on track - If a step could fail, address it immediately (not in a separate troubleshooting section at the end) - Test every command/step mentally — would this actually work? </constraints>

<task> Write release notes for version [X.Y.Z] based on these changes: [paste commit messages, PR descriptions, or change list] Structure: 1. One-line summary of the release 2. Highlights (2-3 most impactful changes, written for users not developers) 3. New features (with brief descriptions of what each enables) 4. Improvements (performance, UX, or quality-of-life changes) 5. Bug fixes (grouped by area if there are many) 6. Breaking changes (with migration steps) 7. Known issues (if any) </task> <constraints> - Write for users, not developers — "faster page loads" not "optimized SQL queries" - Breaking changes must include step-by-step migration instructions - Don't pad thin releases — if there are only 3 changes, that's fine - Use present tense: "Adds dark mode" not "Added dark mode" - No internal jargon or ticket numbers in the public notes </constraints>

<context> Process: [what process you're documenting] Who follows this process: [role/team] Current state: [is this a new process or documenting an existing one?] Tools involved: [list tools used in the process] </context> <task> Document this process so a new team member can follow it independently: [describe the process step by step, or paste rough notes] Include: 1. Purpose — why this process exists (1-2 sentences) 2. When to use it — triggers or schedules 3. Step-by-step instructions with who does what 4. Decision points — where judgment is required and guidelines for deciding 5. Escalation path — what to do if something goes wrong 6. Definition of done — how to know you're finished </task> <constraints> - Write for someone doing this for the first time, not an expert - Include links/paths to tools and resources (use [LINK: description] placeholders) - Decision points need specific criteria, not "use your judgment" - Include a quick-reference checklist version at the end </constraints>