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

<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>

<context> Original audience: [e.g. engineers, researchers] Target audience: [e.g. executives, non-technical stakeholders, general public] Purpose: [why you're simplifying: blog post, presentation, exec briefing] </context> <task> Simplify this technical content while keeping it accurate: [paste technical content] Rules: 1. Replace jargon with plain English (define terms you must keep) 2. Use analogies to explain complex concepts 3. Lead with the "so what": why should the reader care? 4. Cut details that don't change the reader's understanding or decisions </task> <constraints> - Accuracy is non-negotiable: simple doesn't mean wrong - If simplifying creates a misleading impression, keep the complexity and explain it - Maximum reading level: 8th grade (Hemingway standard) - Each paragraph should be under 3 sentences - Include a "TL;DR" at the top (2-3 sentences) </constraints>

<context> I'm [your role] at [company]. I want to reach [target person's role] at [target company type]. What I'm offering: [value proposition] Why this person specifically: [connection point: mutual contact, their recent work, their company's situation] </context> <task> Write a cold email that gets a reply (not just an open): 1. Subject line (under 40 characters, no clickbait) 2. Opening line that proves I did my homework (reference something specific about them) 3. Value proposition in one sentence 4. Clear, low-commitment ask (not "let's hop on a call") 5. Sign-off </task> <constraints> - Total length: under 100 words (short emails get more replies) - No "I hope this email finds you well" - No "I'd love to pick your brain" - The ask should be answerable in one sentence (makes replying easy) - Sound like a person, not a template </constraints>

<context> Situation: [describe the issue: disagreement, feedback, boundary setting, bad news] My relationship with this person: [colleague, manager, client, direct report] What I want to achieve: [desired outcome] What I want to avoid: [what would make this worse] </context> <task> Write an email that handles this situation: [describe specifically what needs to be communicated] The email should: 1. Be direct about the issue without being aggressive 2. Acknowledge their perspective 3. State what I need clearly 4. Propose a path forward </task> <constraints> - No passive-aggressive language - No "per my last email" or similar - Don't over-apologize: be confident and fair - Keep it under 150 words (long emails escalate tension) - Read it in the worst possible tone: does it still come across okay? </constraints>

<task> Write a [weekly/monthly] status update for [audience: team, manager, stakeholders]: Project: [project name] Period: [date range] Raw updates: [paste your bullet points, notes, or highlights] </task> <format> Structure: 1. **TL;DR** (2 sentences: what matters most) 2. **Progress** (what moved forward, with specifics) 3. **Blockers** (what's stuck and what you need) 4. **Next week** (what's planned) 5. **Decisions needed** (if any: make it easy to decide by including options) </format> <constraints> - TL;DR first: most people won't read past it - Use bullet points, not paragraphs - Include numbers where possible (% complete, days remaining, metrics) - Blockers must include what you need from whom - Keep it under 200 words total </constraints>

<context> Occasion: [e.g. after a meeting, job interview, received help, conference connection] Recipient: [their name and role] What happened: [specific detail about the interaction] What I want next: [if anything: next meeting, keep in touch, next steps] </context> <task> Write a follow-up email that: 1. Thanks them for something specific (not just "thanks for your time") 2. References a concrete detail from our interaction (proves I was paying attention) 3. Adds value: shares something useful related to what we discussed 4. Includes a clear next step (if appropriate) </task> <constraints> - Under 80 words (short follow-ups are more memorable) - Send-ready tone: not overly formal or overly casual - No "as discussed" or "as per our conversation" - The value-add should be genuine (an article, an intro, an insight: not fluff) </constraints>