30 Claude Prompts for Style Guides

You are an editorial terminology lead. <context> Writers use different words for the same concept across articles, which confuses readers and hurts search consistency. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Industry or beat: [INDUSTRY_OR_BEAT] - Terms that get used inconsistently: [INCONSISTENT_TERMS] - Audience sophistication level: [AUDIENCE_LEVEL, e.g. beginner, expert] </inputs> <task> Build a glossary of 15 terms showing the preferred term, terms to avoid for the same concept, and a one-line reason, prioritizing the inconsistent terms supplied. </task> <constraints> - Every term supplied as inconsistent must appear in the glossary with a resolved preferred version. - Reasons must reference the audience level, not be generic. - No two glossary rows may describe the same underlying concept. </constraints> <format> Return a table with columns: Preferred Term, Avoid, Why. </format>

You are a copy editor. <context> Product and feature names get capitalized differently article to article, and legal or product teams have specific requirements for how names should appear. </context> <inputs> - Publication or company name: [PUBLICATION_NAME] - Product and feature names with correct casing: [PRODUCT_NAMES_WITH_CASING] - Names competitors or writers commonly get wrong: [COMMON_MISTAKES] - Content types: [CONTENT_TYPES] </inputs> <task> Build a reference table listing each product or feature name in its correct casing, the most common incorrect version seen, and a rule for how to reference it on first mention versus subsequent mentions in the same piece. </task> <constraints> - Use the exact casing supplied for every product name, do not normalize or guess a different casing. - Cover the common mistakes supplied explicitly as "incorrect" entries. - State the first-mention rule (for example, full name plus short name in parentheses) once and apply it consistently. </constraints> <format> Return a table with columns: Correct Name, Common Mistake, First Mention Rule, Subsequent Mention Rule. </format>

You are a copy editor. <context> Writers use acronyms without spelling them out, and different pieces spell the same acronym out differently on first use. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Industry or beat: [INDUSTRY_OR_BEAT] - Acronyms used often: [COMMON_ACRONYMS] - Audience familiarity level: [AUDIENCE_FAMILIARITY, e.g. industry expert, general reader] </inputs> <task> Build a reference guide listing each common acronym, its full spelled-out form, whether it needs to be spelled out on first use for the stated audience, and one example sentence showing correct first-use formatting. </task> <constraints> - Every acronym supplied must appear with its exact correct expansion. - If the audience is described as industry expert, mark widely-known acronyms as not needing first-use expansion, and state why. - Example sentences must be realistic for the stated industry, not generic. </constraints> <format> Return a table with columns: Acronym, Full Form, Needs First-Use Expansion (Y/N), Example Sentence. </format>

You are a plain-language editor. <context> Drafts are full of internal or industry jargon that makes sense to the writer but loses general readers. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Industry or beat: [INDUSTRY_OR_BEAT] - Jargon terms that appear often: [JARGON_TERMS] - Target reading level: [READING_LEVEL, e.g. general public, informed layperson] </inputs> <task> For each jargon term supplied, write a plain-language translation appropriate for the target reading level, and one example sentence showing the term used correctly in context for readers who do need the technical term. </task> <constraints> - Translations must not introduce a different jargon term as the replacement. - Note when a jargon term is unavoidable (no plain equivalent exists) and, in that case, provide a one-sentence explanation to use alongside it. - Keep each translation to one sentence. </constraints> <format> Return a table with columns: Jargon Term, Plain-Language Translation, When to Use the Technical Term Instead, Example Sentence. </format>

You are an editorial style lead. <context> Certain buzzwords and filler phrases keep showing up in drafts and make the writing sound generic instead of specific. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Buzzwords or filler phrases seen often: [BUZZWORDS_SEEN] - Desired tone instead: [DESIRED_TONE] - Content types: [CONTENT_TYPES] </inputs> <task> Build a banned words and phrases list covering the buzzwords supplied plus 5 additional common filler phrases for the stated content types, each with a specific alternative phrasing that fits the desired tone. </task> <constraints> - Every alternative must be a real usable phrase, not another vague filler word. - Give one example sentence per banned term showing the fix applied. - Do not include any hype or marketing buzzwords as the suggested replacement. </constraints> <format> Return a table with columns: Banned Term, Why It's Banned, Alternative, Example Fix. </format>

You are a content editor. <context> Writers use headings inconsistently, sometimes skipping levels or using an H3 where an H2 belongs, which breaks both readability and SEO structure. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES, e.g. blog posts, help docs, landing pages] - Typical article length: [TYPICAL_LENGTH] - SEO priority: [SEO_PRIORITY, e.g. high, medium] </inputs> <task> Define rules for when to use H1 through H4, including how many H2 sections a typical article of the stated length should have, and one example heading at each level for the stated content type. </task> <constraints> - Only one H1 allowed per page, state this explicitly as a rule. - Heading levels must never skip (no H2 straight to H4). - If SEO priority is high, include a note on including target keywords naturally in H2s. </constraints> <format> Return a table with columns: Level, When to Use, Example Heading. </format>

You are a content editor. <context> Bulleted lists across content are inconsistent, some end in periods, some don't, some are full sentences and some are fragments. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Preferred list style: [LIST_STYLE_PREFERENCE, e.g. sentence fragments, full sentences] - One example list from a recent draft: [EXAMPLE_LIST] </inputs> <task> Define rules for bullet point capitalization, punctuation, and parallel structure, then apply the rules to reformat the example list supplied as a corrected version. </task> <constraints> - All bullets in a single list must follow the same grammatical structure (all fragments or all full sentences), state this as a rule explicitly. - Follow the stated list style preference in the corrected example. - Note the rule for when to use a numbered list instead of bullets (sequential steps). </constraints> <format> Return a table of rules with columns Rule, Decision, Example, followed by the corrected version of the supplied example list. </format>

You are a content editor. <context> Writers start each blog post from a blank page and structure varies wildly, making some posts hard to skim. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Typical blog post topic type: [TOPIC_TYPE, e.g. how-to, listicle, opinion] - Target word count: [TARGET_WORD_COUNT] - SEO priority: [SEO_PRIORITY] </inputs> <task> Build a section-by-section structure template for the stated blog post topic type, naming each section, its purpose, and an approximate word count that adds up to the target total. </task> <constraints> - Section word counts must sum to within 10 percent of the target word count. - Include an introduction section with a stated maximum length (for example, under 100 words). - If SEO priority is high, include a section note on where the primary keyword should appear. </constraints> <format> Return a table with columns: Section, Purpose, Approx. Word Count. </format>

You are a content editor. <context> Writers cite sources and add links inconsistently, some as plain URLs, some as vague "according to a study", with no consistent rule. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Types of sources cited often: [SOURCE_TYPES, e.g. studies, news articles, internal data] - Link style preference: [LINK_STYLE, e.g. inline hyperlink, footnote] </inputs> <task> Define rules for how to cite each type of source supplied, how to format the link itself following the stated style preference, and one example sentence per source type showing a correctly formatted citation. </task> <constraints> - Every citation must name the actual source in the visible text, not just a bare hyperlink with no attribution. - Follow the stated link style preference consistently across all examples. - State the rule for citing internal data or company sources differently from external sources. </constraints> <format> Return a table with columns: Source Type, Citation Rule, Example Sentence. </format>

You are a content editor. <context> Tables and data callouts across content use different header styles, number formats, and units, which makes the site feel inconsistent. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Common data types shown: [DATA_TYPES, e.g. percentages, prices, dates] - One example table from a recent draft: [EXAMPLE_TABLE] </inputs> <task> Define formatting standards for table headers (capitalization, alignment), how to display each of the common data types supplied, and units of measurement, then apply the standards to reformat the example table supplied. </task> <constraints> - Header capitalization rule must apply consistently to every header in the corrected example. - Numeric columns must right-align, text columns must left-align, state this as a rule. - Every data type supplied must have an explicit display rule (for example, percentages always to one decimal place). </constraints> <format> Return a table of rules with columns Rule, Decision, followed by the corrected version of the supplied example table. </format>

You are an editorial voice lead. <context> Multiple writers contribute content and their sentences read noticeably differently in length, formality, and directness. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Target reading level: [READING_LEVEL, e.g. 8th grade, informed layperson] - Preferred sentence style: [SENTENCE_STYLE, e.g. short and direct, varied length] - 2 real sentences from a piece that reads exactly right: [MODEL_SENTENCES] </inputs> <task> Build an editorial voice chart defining rules for sentence length, active versus passive voice, contraction use, and directness, using the 2 model sentences as reference examples of the target voice. </task> <constraints> - State an explicit average sentence length target consistent with the reading level. - Active voice preference must include a rule for the rare cases passive voice is acceptable. - Reference the 2 model sentences directly in at least one rule as the standard to match. </constraints> <format> Return a table with columns: Rule, Target, Example. </format>

You are an editorial voice lead. <context> A support doc should read differently from a blog post or a social caption, but writers default to one tone across every content type. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types to cover: [CONTENT_TYPES, e.g. blog, support docs, social captions] - Core voice adjectives: [VOICE_ADJECTIVES] - One example piece we already published: [EXAMPLE_PIECE] </inputs> <task> Build a tone calibration table showing how formal and how warm the writing should be for each content type listed, and a sample opening sentence per content type that fits that calibration. </task> <constraints> - Score formality and warmth on a 1 to 5 scale with a one-line reason for each score. - Keep every sample sentence consistent with the core voice adjectives even as formality shifts. - Support docs must score lower on "clever" phrasing than blog or social content, note this explicitly. </constraints> <format> Return a table with columns: Content Type, Formality (1-5), Warmth (1-5), Sample Opening Sentence. </format>

You are a senior copy editor. <context> Drafts often default to passive voice, wordy phrasing, and weak verbs, and writers learn faster from seeing the fix applied than from a rule alone. </context> <inputs> - Publication name: [PUBLICATION_NAME] - 4 real sentences from recent drafts: [REAL_SENTENCES] - Target voice adjectives: [VOICE_ADJECTIVES] - Common issue types seen: [ISSUE_TYPES, e.g. passive voice, wordiness, weak verbs] </inputs> <task> For each of the 4 real sentences, identify the specific issue from the types listed, rewrite the sentence to fix it while preserving the original meaning, and explain in one line what changed. </task> <constraints> - Every rewrite must be measurably shorter or more direct than the original, unless the fix is specifically about clarity rather than length. - Explanation must name the issue type explicitly, not just say "tightened". - Preserve any factual claims or numbers exactly as given in the original. </constraints> <format> Return a table with columns: Original Sentence, Issue Type, Rewritten Sentence, What Changed. </format>

You are a content strategist. <context> Writers don't have a clear picture of who they're actually writing for, so vocabulary and sentence complexity vary randomly. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Primary audience description: [AUDIENCE_DESCRIPTION] - Content types: [CONTENT_TYPES] - Topics covered: [TOPICS] </inputs> <task> Define a reader persona summarizing who the primary audience is and what they already know, then set a target reading level (using a Flesch-Kincaid grade level range) appropriate for that persona and the topics covered. </task> <constraints> - Persona must be specific enough to guide word choice decisions, not a vague "busy professional" description. - Reading level target must be a specific grade range (for example, 8th to 10th grade), not "accessible". - Note one specific vocabulary adjustment writers should make to hit that target given the stated topics. </constraints> <format> Return a structured doc with sections: Reader Persona, Target Reading Level, Vocabulary Guidance. </format>

You are an editorial style lead. <context> Some pieces are written in first person, some in third, and pronoun and contraction use varies without a stated rule. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Preferred point of view: [POV_PREFERENCE, e.g. first person plural, third person] - Contraction preference: [CONTRACTION_PREFERENCE, e.g. allowed, avoided in formal pieces] </inputs> <task> Define point-of-view rules (which pronoun to use when referring to the company and to the reader), contraction rules by content type, and one example paragraph demonstrating the rules applied correctly. </task> <constraints> - State explicitly which pronoun refers to the company and which refers to the reader, with no ambiguity. - Contraction rule must vary by content type if the stated preference differs between formal and informal pieces. - Example paragraph must be at least 3 sentences and follow every rule stated above it. </constraints> <format> Return a structured doc with sections: Point of View Rules, Contraction Rules, Example Paragraph. </format>

You are an editorial inclusivity lead. <context> Writers unintentionally use outdated or exclusionary terms because there's no single reference for current preferred language. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Topics covered: [TOPICS] - Terms flagged as outdated or exclusionary in past feedback: [FLAGGED_TERMS] - Audience: [AUDIENCE_DESCRIPTION] </inputs> <task> Build an inclusive language guide covering the flagged terms supplied plus 5 additional commonly misused terms relevant to the stated topics, each with the preferred term, a one-line rationale, and an example sentence. </task> <constraints> - Every flagged term supplied must appear with a clear preferred replacement. - Rationale must explain why the preferred term is more accurate or respectful, not just assert it. - Avoid absolute claims about what all members of any group prefer, note where usage varies by individual or context. </constraints> <format> Return a table with columns: Term to Avoid, Preferred Term, Rationale, Example Sentence. </format>

You are an accessibility-focused content editor. <context> Content needs to be usable by readers using screen readers or with cognitive or visual differences, and there's no standing checklist to catch common issues before publishing. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Platform or CMS used: [PLATFORM] - Common accessibility gaps seen before: [PAST_GAPS] </inputs> <task> Build a pre-publish accessibility checklist covering alt text for images, plain language, link text clarity (no "click here"), and heading structure for screen readers, prioritizing the past gaps supplied. </task> <constraints> - Every past gap supplied must map to a specific checklist item that would have caught it. - Alt text rule must state what makes alt text useful versus decorative-only, not just "add alt text". - Link text rule must give at least 2 concrete rewrites of "click here" style links. </constraints> <format> Return a live HTML artifact with a checkbox-style checklist. </format>

You are an editorial inclusivity lead. <context> Drafts sometimes carry unconscious bias in examples used, like defaulting to one gender for a profession, and writers want to catch this before publishing. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Topics covered: [TOPICS] - 3 real example sentences from past drafts: [REAL_EXAMPLES] - Audience: [AUDIENCE_DESCRIPTION] </inputs> <task> Review the 3 real example sentences for bias in gender, age, ability, or cultural assumptions, explain the specific bias found in each, and rewrite each sentence to remove it while preserving the original point. </task> <constraints> - Explanation must name the specific type of bias, not just flag the sentence as "off". - Rewrite must preserve the factual content and tone, only the biased assumption changes. - If a sentence has no bias issue, state that explicitly rather than forcing a change. </constraints> <format> Return a table with columns: Original Sentence, Bias Identified, Rewritten Sentence. </format>

You are a localization-aware copy editor. <context> Content reaches readers in multiple English-speaking regions and spelling, date formats, and measurement units need a consistent rule. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Primary region: [PRIMARY_REGION, e.g. US] - Other regions reached: [OTHER_REGIONS, e.g. UK, Australia, Canada] - Measurement unit preference: [UNIT_PREFERENCE, e.g. imperial, metric, both] </inputs> <task> Define which regional spelling convention to standardize on, how to handle date formats and measurement units for the regions listed, and a rule for whether to convert or note both units when relevant. </task> <constraints> - Pick one spelling standard (based on the primary region) and state it as the single rule, no mixed spelling within one piece. - If unit preference is "both", state the exact format for showing both (for example, primary unit with the converted unit in parentheses). - Note one commonly confused word that differs by region (for example, "program" vs "programme") as a worked example. </constraints> <format> Return a structured doc with sections: Spelling Standard, Date Format, Measurement Units, Example. </format>

You are an editorial risk-aware editor. <context> Content occasionally touches sensitive subjects and writers need clear framing guidance so pieces don't come across as dismissive or alarmist. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Sensitive topics that come up: [SENSITIVE_TOPICS, e.g. layoffs, mental health, financial hardship] - Audience: [AUDIENCE_DESCRIPTION] - Past feedback or complaints received: [PAST_FEEDBACK] </inputs> <task> For each sensitive topic listed, define a framing rule (tone to use, language to avoid, whether a disclaimer is needed) and one example sentence showing the topic handled appropriately. </task> <constraints> - Address any past feedback supplied directly in the relevant topic's framing rule. - Do not include actual medical, legal, or financial advice in any example, frame examples as informational only. - Note explicitly when a topic should be reviewed by a subject-matter expert or a licensed professional before publishing, not just edited for tone. </constraints> <format> Return a table with columns: Topic, Framing Rule, Language to Avoid, Example Sentence, Review Needed (Y/N). </format>

You are an editorial director. <context> A content team is building an editorial style guide from scratch and needs the full structure before writing any section. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types produced: [CONTENT_TYPES] - Existing rules already decided, if any: [EXISTING_RULES] - Target document length: [LENGTH_TARGET, e.g. 10-15 pages] </inputs> <task> Build a full table of contents for an editorial style guide sized to the target length, with a one-sentence summary of what each section covers, ordering sections from grammar fundamentals through voice and inclusive language. </task> <constraints> - Number of top-level sections must roughly match the target length (about 1 section per 1 to 2 pages). - Include a dedicated section for inclusive language, not folded into general grammar. - Note any existing rules supplied under the section they belong to. </constraints> <format> Return a numbered outline with section titles and one-line summaries. </format>

You are an editorial director. <context> Most writers won't read a full style guide before drafting, they need one page they can keep open while writing. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Top 5 grammar and formatting rules: [TOP_RULES] - Top 3 voice adjectives: [VOICE_ADJECTIVES] - One example on-brand sentence: [EXAMPLE_SENTENCE] </inputs> <task> Condense the top 5 rules and top 3 voice adjectives into a single quick-reference page that a writer can scan in under 30 seconds while drafting. </task> <constraints> - No more than 8 total items on the page. - Include the example sentence as a live illustration of the voice, not just listed as text. - Every one of the 5 rules and 3 adjectives supplied must appear, do not substitute different ones. </constraints> <format> Return a live HTML artifact styled as a compact one-page reference card. </format>

You are an editorial director. <context> A freelance writer or contractor is about to submit their first piece and has never seen the internal style guide. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Freelancer or contractor name: [CONTRACTOR_NAME] - Assignment topic and word count: [ASSIGNMENT_DETAILS] - Key rules they must follow: [KEY_RULES] </inputs> <task> Write a style brief that orients the freelancer to the publication's voice, the key grammar and formatting rules that matter most, and exactly what to do before submitting their draft. </task> <constraints> - Keep the brief short enough to read in under 5 minutes. - Every key rule supplied must be included, not summarized away. - End with a clear submission checklist (word count, sources cited, headline format) before they turn in the draft. </constraints> <format> Return a structured doc with sections: Welcome, Voice Summary, Key Rules, Submission Checklist. </format>

You are an editorial director. <context> The style guide has changed and writers using the old rules need to know exactly what's different and what to update in drafts already in progress. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Previous version number and date: [PREVIOUS_VERSION_AND_DATE] - What changed: [WHAT_CHANGED, e.g. number formatting, banned words, POV rule] - Reason for the change: [REASON_FOR_CHANGE] - New version number: [NEW_VERSION] </inputs> <task> Write a version changelog entry documenting exactly what changed and why, and a specific action-required list of what writers need to fix in drafts already in progress because of this change. </task> <constraints> - Action-required items must be concrete tasks ("replace all instances of X with Y in in-progress drafts"), not vague reminders. - State a deadline placeholder for when the old rule stops being valid. - Keep the reason section to 2 sentences maximum. </constraints> <format> Return a structured changelog entry with fields: Version, Date, Changes, Reason, Action Required. </format>

You are a managing editor. <context> Editors review drafts against the style guide manually and inconsistently, some catch every rule, others miss the same issues repeatedly. </context> <inputs> - Publication name: [PUBLICATION_NAME] - Content types: [CONTENT_TYPES] - Top rule categories to check: [RULE_CATEGORIES, e.g. grammar, terminology, inclusive language, formatting] - Editor experience level: [EDITOR_LEVEL, e.g. new editor, senior editor] </inputs> <task> Build a pre-publish review checklist covering each rule category listed, with specific checklist items an editor can verify quickly against a draft before it publishes. </task> <constraints> - Each rule category must get at least 3 specific checklist items, not one vague line. - Order the checklist so factual and sensitive-content checks come before minor style checks. - If the editor level is "new editor", include a one-line reminder of why each category matters, not just the check itself. </constraints> <format> Return a live HTML artifact with a checkbox-style checklist grouped by rule category. </format>