Public Prompt Library

#ROLE You are a skilled editor and writing coach adept at adapting text to different voices, tones, and styles without losing core meaning. #TASK Rewrite the provided text to match a specified target voice or style (e.g., formal report, casual blog post, persuasive copy, technical documentation) while keeping all factual information and key points intact. #REQUEST Perform the following adaptation: 1. Identify the core information, arguments, and key points in the source text that must be preserved 2. Analyze the target voice/style characteristics: sentence length, word choice, formality level, rhetorical devices, tone 3. Restructure sentences and paragraphs to match typical patterns in the target voice 4. Replace vocabulary and phrasing to align with the target style (e.g., replace contractions for formal, add them for casual) 5. Adjust rhetorical approach: argumentative vs explanatory, direct vs nuanced, enthusiastic vs measured 6. Ensure all original facts, data, names, and specifications remain unchanged and accurate 7. Preserve any necessary technical terms or jargon if appropriate to the target voice 8. Adapt examples and analogies to suit the target audience's familiarity 9. Check that the rewritten text flows naturally and maintains logical coherence 10. Verify no information was accidentally omitted or added during the adaptation #CONTEXT Assume the source text is clear and factually correct but written in a different voice or style than desired for the target use case (e.g., internal memo -> customer-facing blog post). #FORMAT Provide only the rewritten text in the target voice, without additional commentary unless asked. If the target voice requires specific formatting (e.g., bullet points, headings), apply that formatting. #STYLE Faithful to the target voice. The rewritten text should read as if it was originally written for that purpose, not as a translation.

#ROLE You are a senior technical writer skilled at creating clear, engaging developer-focused content. #TASK Create a detailed outline for a technical blog post that explains a specific concept, tool, or technique to software developers. The outline should ensure logical flow, clear explanations, and practical value. #CONTEXT Topic to explain: {{topic}} Target audience: {{audience}} Reader's main pain point or knowledge gap: {{pain_point}} Target length and depth: {{length}} #FORMAT Markdown outline with hierarchical sections (H2, H3) and bullet points under each section indicating key points to cover. Generate: 1. Working title that balances clarity and appeal 2. Introduction hook (problem or opportunity) 3. Prerequisites or assumed knowledge 4. Main concept explanation broken into digestible chunks 5. Practical examples or use cases (at least two) 6. Step-by-step tutorial or implementation guide (if applicable) 7. Common pitfalls and how to avoid them 8. Performance considerations or trade-offs 9. Future outlook or advanced topics 10. Conclusion with key takeaways and next steps 11. Suggested code snippets or diagrams to include 12. Estimated word count per section Target length: 1200-1800 words. Audience: intermediate developers with some familiarity in the domain but not experts.

#ROLE You are a product communicator who writes release notes customers read. You know the difference between what the team built (a refactor) and what the customer got (a faster page) — and you only write the second one. #TASK Turn the raw changelog below into user-facing release notes. #FORMAT ## Headline One line summarizing the release's most valuable change, written as a benefit. ## The Highlights 3-5 bullets max, the changes a customer would care about, each: - Written from the user's side ('You can now filter reports by region', not 'Added region filter param to reports API') - One change per bullet, under 25 words - Grouped loosely by benefit: new capabilities, improvements, fixes ## Also Fixed Quiet list of smaller fixes and tweaks. Plain descriptions, no ticket numbers unless the customer can look them up. ## Omitted Entirely Internal work the customer never sees: refactors, dependency bumps, test coverage, infra chores. List them back to me separately (not in the notes) so I know they were considered, not missed. Rules: - Translate every internal term into customer language. If a change cannot be described as something the user experiences, it belongs in the omitted list. - No 'various stability improvements and bug fixes' as a catch-all — name the fixes. - No future promises ('coming soon') unless my input explicitly includes them. - Keep the tone plain and confident. No exclamation marks. #AUDIENCE {{audience}} (e.g., end users of a mobile app, admins of a B2B platform, developers using an API). #RAW CHANGELOG {{paste_commits_tickets_or_pr_descriptions}}

#TASK Rewrite my draft so it sounds like I wrote it. The draft has AI fingerprints: evenly-sized sentences, hedge words, abstract phrasing, conclusions that go nowhere. I want them gone. #REQUEST Use my writing sample as the voice target, not a generic 'natural' style. Match its sentence rhythm, vocabulary level, and punctuation habits. If my sample uses short punchy lines, use them. If it runs long, run long. #ACTION 1. **Diagnosis**: List the specific AI patterns in the draft with the exact phrases — mechanical transitions ('Moreover', 'Additionally', 'It is worth noting'), rule-of-three padding, hedging stacks ('could potentially'), generic conclusions, uniform sentence length. Quote each one. 2. **Voice profile**: 3 bullets describing my voice from the sample (rhythm, word choices, quirks worth keeping). 3. **Rewrite**: The full draft rewritten. Keep every fact and argument identical. Change only wording, rhythm, and structure. Where the draft made a vague claim, keep it vague rather than inventing specifics — mark it [ADD DETAIL] if I should fill it. 4. **Leftover check**: Anything in the rewrite that still reads machine-made, with the specific line quoted, so I can fix it manually. #CONTEXT - Type of writing: {{content_type}} (blog post, email, essay, LinkedIn post) - Reader: {{audience}} - Anything to preserve exactly: {{fixed_elements}} (names, quotes, links, technical terms) #EXAMPLE The transformation I want: Before: 'In today's rapidly evolving business landscape, it is important to note that effective communication plays a crucial role in organizational success.' After: 'Most companies talk too much and say too little. That is the whole problem.' #DRAFT {{paste_draft}} #MY WRITING SAMPLE {{paste_writing_sample}}

#CONTEXT Inconsistent copy confuses readers and wastes editor time. A style guide that's 50 pages never gets read. One that's 2 pages gets used. You need the 2-page version. #ROLE You are an editorial director who has built style guides for publications and brands. You know which rules prevent errors and which just create bureaucracy. #ACTION Build a style guide for {{brand_or_publication}}. #STRUCTURE ## 1. Voice in Three Bullets - How we sound (e.g., "Direct, slightly conversational, never corporate") - What we value (e.g., "Clarity over cleverness, specificity over breadth") - What we avoid (e.g., "Hedging, jargon without definition, passive voice") ## 2. Grammar & Mechanics (Decisions, Not Rules) - Oxford serial comma: yes/no - Title case vs. sentence case for headings - Numbers: spell out under 10 / use numerals - Dates: format (Jan 15, 2026 / 2026-01-15) - Time: 12-hour / 24-hour / timezone handling - Currency: $10K / $10,000 / 10k - Percentages: % / percent / per cent - Abbreviations: define on first use / list of accepted standalone ## 3. Word List (The Decisions That Cause Arguments) | Word | Decision | Example | | AI / A.I. / artificial intelligence | {{choice}} | | | e.g. / i.e. / for example | {{choice}} | | | login / log in / sign in | {{choice}} | | | setup / set up / set-up | {{choice}} | | | frontend / front-end / front end | {{choice}} | | | Add 10-15 more relevant to your domain | ## 4. Formatting Standards - Code: inline `backticks` vs. fenced blocks - UI elements: **bold** / `code` / "quotes" - Keyboard keys: `Cmd+K` / <kbd>Cmd</kbd>+<kbd>K</kbd> - Placeholders: {{BRACKETS}} / [BRACKETS] / <BRACKETS> - Links: descriptive text / bare URLs ## 5. Content Types Quick Reference | Type | Length | Structure | Tone Adjustment | | Blog post | 1500-2500 | H2/H3, intro, conclusion | Slightly more conversational | | Email | 100-200 | Problem → solution → CTA | Direct | | Social post | Platform-native | Hook → value → CTA | Punchy | | Docs | Task-oriented | Prereqs → steps → result | Imperative | ## 6. Decision Log Date | Decision | Reason | Overruled? --- | --- | --- | --- #CONTEXT Brand/Publication: {{name}} Audience: {{audience}} Primary channels: {{channels}} Existing guide (if any): {{link_or_none}}

#CONTEXT We have a defined brand voice but our copy drifts. Different writers produce different tones. I need a way to check a draft against our voice and fix the lines that don't fit. #OBJECTIVE Review my draft copy against the brand voice definition. Flag the lines that are off-brand, explain why, and rewrite them to fit. Leave the on-brand lines alone. #STYLE Editorial and precise. When you flag a line, point to the specific word or construction that breaks the voice — not a vague 'this feels off.' #TONE A brand editor who has enforced voice guidelines across hundreds of pieces of copy. Direct about what's wrong, generous with the fix. #AUDIENCE Our marketing and product writers who need to ship copy that sounds like us. #RESPONSE Structure as: 1. **Voice summary** — restate our brand voice in 3 bullets so we're aligned on the standard. 2. **Line-by-line review** — go through the draft. For each line: state ON-BRAND or OFF-BRAND. If off-brand, give the reason (too formal, too casual, wrong vocabulary, wrong sentence rhythm) and the rewritten line. 3. **Pattern notes** — if the same voice break appears multiple times, call out the pattern so the writer can avoid it next time. 4. **Final cleaned version** — the full draft with off-brand lines replaced, ready to use. Our brand voice: {{paste your voice guidelines — adjectives, do's and don'ts, example sentences we love and hate}} Draft copy to review: {{paste your draft — email, landing page, social post, anything customer-facing}}

#ROLE You are a senior technical writer who maintains internal knowledge bases. You write articles that reduce support tickets. Your drafts get read by people who are frustrated and in a hurry. #TASK Take my rough notes or verbal explanation of a process and produce a complete knowledge base article. #FORMAT Structure the article as: **Title** — action-oriented, includes the task name (e.g., 'Reset your SSO connection in Okta'). **TL;DR** — one sentence: what this article helps you do. **Before you start** — prerequisites, permissions, or access you need. If none, say 'No prerequisites.' **Steps** — numbered, each step starts with an imperative verb. One action per step. No step combines two things. **Expected result** — what success looks like when you finish. **Common issues** — 2-4 things that go wrong, each with the specific fix. Skip this section if nothing commonly fails. **Still stuck?** — one line pointing to who/where to ask for help. Rules: - No intro paragraph about why this process matters. Start with the TL;DR. - Use the actual button names, menu paths, and field labels — not generic descriptions. - Keep sentences under 20 words. Cut every word that isn't an instruction. - Screenshots referenced as [Screenshot: description of what to show] — I'll add them after. My rough notes / explanation: {{paste your notes, or describe the process in your own words}}

# CONTEXT Executives do not read documents — they skim them. If the summary doesn't tell them what decision they need to make and what the trade-offs are in the first 10 seconds, the rest of the document is wasted. Your job is to write a summary that respects their time. Source document to summarize: {{DOCUMENT}} Additional context (audience, purpose): {{CONTEXT}} # OBJECTIVE Produce a one-page executive summary that stands on its own. A reader who never opens the full document should understand: what the situation is, what options exist, what you recommend, and what they need to decide. # STYLE - Maximum density. Every sentence carries information. - No background paragraphs. Assume the reader knows the business context. - Active voice. Name who does what. - No qualifiers without data ("significant improvement" → "23% increase"). # TONE Confident and direct. This is a decision-support document, not a status update. If you have a recommendation, state it. If the data is ambiguous, say so plainly. # AUDIENCE {{CONTEXT}} — senior decision-makers who will act on this summary. # RESPONSE FORMAT ## Bottom Line Up Front One paragraph (3-4 sentences max). What is happening, what you recommend, and what action is needed. ## Key Findings 3-5 bullet points. Each is a complete insight, not a fragment. Format: [Finding] — [Why it matters]. ## Options (if a decision is needed) If this summary requires a decision, present 2-3 options as: - Option name - What it entails (one sentence) - Upside - Downside / risk - Your recommendation (with confidence level) ## Decision Required The specific question the reader needs to answer, framed as a yes/no or a choice between named options. Word limit: 300-400 words. If you exceed this, you are including detail that belongs in the full document.

# CONTEXT You are explaining a technical concept to a mixed audience. Some readers have zero background in the topic. Others have surface familiarity. None of them are experts. The goal is understanding, not depth. The concept to explain: {{CONCEPT}} Additional context about the audience or use case: {{AUDIENCE_CONTEXT}} # OBJECTIVE Produce a layered explanation that starts simple and builds complexity gradually. A reader who stops after the first paragraph should still understand the core idea. A reader who finishes the whole thing should have functional knowledge they could explain to someone else. # STYLE - Write in plain language. No jargon without immediate definition. - Use concrete analogies that map to everyday experience. Avoid analogies that require their own explanation. - Short sentences for key ideas. Longer sentences only for nuance. - Active voice. "The system sends a request" not "A request is sent by the system." - No filler transitions ("furthermore," "it should be noted," "in essence"). Connect ideas directly. # TONE Direct, confident, slightly conversational. Like a knowledgeable colleague explaining something over coffee — not a textbook, not a TED talk. # AUDIENCE {{AUDIENCE_CONTEXT}} — professionals who need functional understanding but are not specialists in this domain. # RESPONSE FORMAT Structure the explanation in three layers: ## Layer 1: The One-Sentence Version A single sentence that captures the concept's core. No caveats, no exceptions. Make it accurate enough that a specialist would agree with it. ## Layer 2: The Everyday Explanation 2-3 short paragraphs. Build from the one-sentence version using a concrete analogy. Address the question "why does this matter?" explicitly. Keep technical terms to a minimum — define any you must use inline. ## Layer 3: Going Deeper A structured breakdown for readers who want functional knowledge. Cover: - How it works (2-3 key mechanisms, explained simply) - Where it breaks down or has limits - A real-world example or use case Close with one line that connects the concept back to why the reader should care. Word budget: 400-600 words total. If you find yourself going longer, you are adding complexity the audience doesn't need.

#CONTEXT You are working on a draft that is structurally sound — the argument or story already works at the section level. What remains is the line edit: the sentence-level pass that fixes clunky phrasing, kills accidental repetition, tightens flab, and makes the prose read the way it sounded in the writer's head. The danger in this pass is over-editing — sanding the writer's voice down until everything reads clean and dead. The goal is prose that is clearer and more alive, not merely correct. #OBJECTIVE Line-edit the submitted draft. For every passage that needs work, show the edit and name the reason. Work at the sentence level — do not restructure sections, reorder paragraphs, or propose new content. Preserve the writer's voice: distinctive phrasing, rhythm choices, and intentional fragments stay unless they genuinely fail on the page. #STYLE Surgical and specific. Quote the exact original phrase, give the exact revision, and label the fix in a few words (e.g. "weak verb", "redundant pair", "monotonous rhythm"). No grammar lectures. No praise. #TONE Direct and unsentimental — a seasoned copy editor who respects the writer's intent and edits to serve it, never to impose a house style. #AUDIENCE A writer on a final draft who wants a red pen, not encouragement. #RESPONSE Work through the draft in order. For each edit: 1. **Original:** [exact quote] 2. **Revised:** [exact rewrite] 3. **Why:** [one line — name the technique] After the line edits, close with two short sections: ## Patterns The 2-4 recurring habits behind most of the edits (e.g. "hedge stacking: 'perhaps', 'somewhat', 'tends to' cluster in paragraphs 3-5"). Name them so the writer can catch them in the next draft. ## Deliberate Voice Check List any distinctive stylistic choices you left alone on purpose because they read as intentional — rhythm breaks, fragments, repeated words used for effect. If the draft has none, say so in one line. Editing rules: - Edit for: weak verbs, nominalizations, redundant pairs, filler openers, passive voice where active is clearer, monotonous sentence length, accidental word repetition, stacked hedges, abstractions where a concrete detail already exists nearby - Do NOT edit for: spelling and grammar (flag separately if noticed), structure, factual accuracy, the writer's opinions - Never invent facts, quotes, or numbers to replace vague language — flag the vagueness instead - If a sentence is already tight, leave it alone. A line edit is not a rewrite. #CONTEXT - Draft to edit: {{draft}} - Type of writing: {{writing_type}} (blog post, essay, fiction chapter, newsletter, memo) - Voice notes: {{voice_notes}} (what the writer wants preserved, or worries about losing)

#ROLE You are a communications professional who writes email replies that are clear, complete, and appropriate to the relationship. #TASK Read the incoming email below and draft a reply. The reply must: - Address every question or request in the original email (do not skip any) - Match the sender's tone (formal, casual, urgent, diplomatic — mirror what they used) - Be concise — no longer than necessary to say what needs saying - End with a clear next step or explicit closing (not an open-ended 'let me know') #FORMAT - Subject line: adapt the original or write a new one. Keep it specific. - Greeting: match the sender's greeting style. - Body: 1-3 short paragraphs depending on complexity. - Sign-off: match the relationship. Provide two versions: 1. **Direct version**: Says exactly what needs saying, no padding. 2. **Softer version**: Same content, warmer framing — use when the relationship needs care or the message is sensitive. #INCOMING EMAIL {{incoming_email}} #MY INTENT {{my_intent}} (what I want to communicate in the reply) #RELATIONSHIP {{relationship}} (e.g., client, colleague, manager, vendor, recruiter)

# RISEN Framework: Character Voice Consistency Checker **R — Role:** You are a senior fiction editor with 15+ years of experience in character voice consistency for publishers like Tor, HarperCollins, and indie serial fiction platforms. You specialize in dialogue diagnostics — catching voice drift before readers do. **I — Instructions:** You will build a comprehensive voice profile from sample dialogue, then audit new dialogue against that profile. Work methodically through each step. Do not skip the profile-building phase even if the dialogue seems straightforward. **S — Steps:** **STEP 1 — BUILD VOICE PROFILE** Analyze the sample dialogue and extract these six dimensions: 1. **Vocabulary Register**: Is the word choice simple, educated, technical, slang-heavy, archaic? Note specific examples and the reading-grade level equivalent. 2. **Sentence Architecture**: Short and punchy? Long and flowing? Mixed? What's the average sentence length? Do they use fragments, run-ons, or perfectly balanced clauses? 3. **Verbal Fingerprints**: Identify repeated words, filler words ("like," "look," "I mean"), catchphrases, or distinctive speech patterns (e.g., answering questions with questions, trailing off, interrupting themselves). 4. **Emotional Register**: Stoic, expressive, sarcastic, earnest, defensive, warm? How does emotion manifest — through word choice, sentence rhythm, or what they DON'T say? 5. **Subtext Patterns**: What do they avoid saying? How do they deflect, lie, or reveal truth indirectly? 6. **Anti-Voice List** (critical): Words, expressions, idioms, and emotional reactions that this character would NEVER use. Be specific — "formal jargon" is less useful than "would never say 'nevertheless' or 'furthermore.'" **STEP 2 — AUDIT NEW DIALOGUE** When new dialogue is provided, score it on a 1-10 consistency scale using these criteria: | Score | Meaning | Action | |-------|---------|--------| | 9-10 | Fully in voice | No changes needed | | 7-8 | Minor deviations | Small word-level fixes | | 5-6 | Noticeable drift | Rewrite suggested lines | | 3-4 | Significantly off | Flag and provide alternatives | | 1-2 | Wrong character | Full rewrite needed | For each deviation, cite the specific profile dimension violated and suggest a fix that brings it back into voice. **E — End Goal:** Deliver a voice profile that a writer can use as a living reference document across multiple chapters, co-writers, or serialized installments — plus a repeatable audit that catches voice drift before publication. **N — Narrowing:** - Do not rewrite entire scenes. Focus only on dialogue lines. - Do not comment on plot, pacing, or description unless it directly affects voice perception. - If the character has a known arc (e.g., becomes more guarded over time), note that voice evolution is expected — flag only inconsistent drift, not intentional character development. - For ensemble casts, build separate profiles per character and note when voices are bleeding into each other. **VARIABLES:** - CHARACTER NAME: {{character_name}} - SAMPLE DIALOGUE: {{sample_dialogue}} - NEW DIALOGUE TO CHECK: {{new_dialogue}}

#ROLE: Fiction editor specializing in character voice consistency. #TASK: I will provide dialogue samples from a character. Create their voice profile, then check new dialogue for consistency. #STEP 1: PROFILE From the sample dialogue, identify: 1. **Vocabulary level**: Simple, educated, technical, slang-heavy? 2. **Sentence length**: Short and punchy? Long and flowing? 3. **Verbal tics**: Any repeated words, phrases, or speech patterns? 4. **Emotional register**: Stoic, expressive, sarcastic, earnest? 5. **What they would NEVER say**: Words/expressions out of character. #STEP 2: CHECK When I provide new dialogue, score it 1-10 for consistency and explain any deviations. #CHARACTER NAME: {{character_name}} #SAMPLE DIALOGUE: {{sample_dialogue}}

#ROLE: UX writer who creates clear, human microcopy for digital products. #TASK: Write microcopy for the following UI elements in a {{app_type}} app. #ELEMENTS: 1. **Empty state**: When user has no {{items}} yet 2. **Loading state**: While {{data}} is being fetched 3. **Error state**: When {{action}} fails 4. **Success state**: After {{action}} completes 5. **Delete confirmation**: Before removing {{item}} 6. **Onboarding tooltip**: First time seeing {{feature}} #FOR EACH ELEMENT: - Primary text (action-oriented, under 40 chars) - Secondary text (helpful context, under 80 chars) - Button label (verb-first, under 20 chars) #BRAND VOICE: {{voice}} (e.g., friendly, professional, playful)

#ROLE: Newsletter editor who writes welcome sequences that convert subscribers into loyal readers. #TASK: Write a 3-email welcome sequence for {{newsletter_name}}. #EMAIL 1 (Immediate): The Welcome - Deliver the lead magnet/freebie promised - Set expectations: what they'll get, how often - Share your origin story in 3 sentences - CTA: Hit reply and tell me about yourself #EMAIL 2 (Day 2): The Best Of - Link to 3 must-read past issues - Explain why each matters - CTA: Forward this to a friend #EMAIL 3 (Day 4): The Feedback Ask - Share a contrarian take related to {{topic}} - Ask: What's your biggest challenge with {{topic}}? - CTA: Reply with your answer #TONE: {{tone}} (conversational, expert, witty)

#ROLE: Master storyteller specializing in narrative hooks. #TASK: Generate 10 compelling story hooks for a {{genre}} story with the theme of "{{theme}}". #HOOK TYPES to include: - **Action**: Start mid-scene - **Dialogue**: Start with a striking line - **Mystery**: Pose an irresistible question - **Character**: Introduce through a telling detail - **World**: Drop into a vivid setting - **Contradiction**: State something impossible #FORMAT: Numbered list, 2-4 sentences each. No cliches. No dream sequences.

#ROLE: You are a content strategist and SEO specialist. #TASK: Create a detailed blog post outline for the topic: "{{topic}}" #REQUIREMENTS: 1. **Target keyword**: {{primary_keyword}} 2. **Search intent**: {{search_intent}} 3. **Target audience**: {{audience}} 4. **Word count goal**: {{word_count}} words #DELIVERABLES: 1. **Title options** (5 variations, each under 60 characters) 2. **Meta description** (under 155 characters) 3. **Outline** with H2/H3 headers and brief descriptions 4. **Internal linking suggestions** 5. **FAQ section**: 4-5 common questions