30 Claude Prompts That Write Knowledge Base Articles

You are a policy writer who turns internal rules into clear, customer-facing help-center policy articles. <context> I need a ready-to-publish refund-and-cancellation policy article for my help center, returned as one self-contained Markdown document written in plain language (not legalese). </context> <inputs> - Product and billing model: [SUBSCRIPTION / ONE-TIME / USAGE] - Refund eligibility window and conditions: [E.G. 14 DAYS, UNUSED] - What is non-refundable: [EXCLUSIONS] - How to cancel and when it takes effect: [CANCEL PROCESS] - What happens to data and access after cancellation: [DATA POLICY] - How refunds are issued and timing: [METHOD + TIMEFRAME] </inputs> <task> Write the policy with: an H1 title, an effective-date line, a plain-language summary of the policy in 2-3 sentences, a "Am I eligible for a refund?" section with clear yes/no conditions, a "What isn't refundable" list, a step-by-step "How to cancel" section, a "What happens after you cancel" section covering access and data, a "How and when you'll get your refund" section, and a "Contact us" footer. Keep it accurate and unambiguous. </task> <constraints> - Valid, self-contained Markdown in plain language; every rule stated as a concrete condition, no vague "may". - Include an effective date and a note that terms may update; do not invent legal guarantees not in the inputs. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full policy as a Markdown artifact, then a note flagging any place where you had to assume a rule the inputs didn't specify. </format>

You are a privacy-focused writer who explains data practices to customers in plain terms. <context> I need a ready-to-publish help-center article explaining how my product handles user data, returned as one self-contained Markdown document. This is a customer-friendly explainer that complements (not replaces) the legal privacy policy. </context> <inputs> - Product: [NAME] - What data you collect and why: [DATA TYPES + PURPOSE] - Where it is stored and for how long: [STORAGE + RETENTION] - Who it is shared with, if anyone: [SUBPROCESSORS / NONE] - User controls available: [EXPORT, DELETE, OPT-OUT] - Relevant frameworks: [GDPR / CCPA / SOC 2 / NONE] </inputs> <task> Write the article with: an H1 title, a one-paragraph plain-language summary, a "What we collect and why" table (data type, purpose, retention), a "Where your data lives" section, a "Who can access it" section covering any third parties, a "Your controls" section explaining how to export or delete data with steps, a compliance note referencing applicable frameworks, and a link-out line to the full legal privacy policy. </task> <constraints> - Valid, self-contained Markdown with a data table; plain language; clearly labeled as an explainer, not the legal policy. - Do not overstate compliance beyond the inputs; give real steps for user data controls; no filler. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full article as a Markdown artifact, then a note on which claims must be verified against your actual legal privacy policy before publishing. </format>

You are a trust-and-safety writer who documents acceptable use rules for a product. <context> I need a ready-to-publish acceptable-use policy article for my help center, returned as one self-contained Markdown document that users can actually understand. </context> <inputs> - Product and what people do with it: [USE CONTEXT] - Behaviors that are prohibited: [PROHIBITED LIST] - Content or actions that are restricted or limited: [RESTRICTIONS] - Consequences of violations: [WARNING / SUSPENSION / BAN] - How to report a violation: [REPORTING CHANNEL] - The appeal process, if any: [APPEALS] </inputs> <task> Write the policy with: an H1 title, an effective-date line, a short plain-language intro on the spirit of the policy, a "What's not allowed" section with grouped, concrete examples for each prohibited category, a "What happens if you break these rules" enforcement-ladder section, a "How to report abuse" section, an "Appealing a decision" section, and a contact footer. Use concrete examples so rules aren't ambiguous. </task> <constraints> - Valid, self-contained Markdown; each prohibited category has at least one concrete example of what does and doesn't cross the line. - Fair, non-threatening tone; enforcement steps stated as a clear ladder; do not invent consequences not in the inputs. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full policy as a Markdown artifact, then a note on where a concrete example would most reduce edge-case disputes. </format>

You are a technical writer documenting service-level and support commitments. <context> I need a ready-to-publish article explaining my product's uptime commitment and support response policy, returned as one self-contained Markdown document. </context> <inputs> - Product and plans covered: [PLANS] - Uptime target and how it is measured: [E.G. 99.9%, MONTHLY] - Support channels and hours by plan: [CHANNELS + HOURS] - Response-time targets by priority level: [P1..P4 TARGETS] - What counts as excluded downtime: [MAINTENANCE, FORCE MAJEURE] - Remedies or credits for missed targets: [SLA CREDITS] </inputs> <task> Write the article with: an H1 title, an effective-date line, a plain-language summary, an "Uptime commitment" section defining the target and how it's measured, a support-response table (priority level, definition, target response, channel), a "Support hours by plan" table, an "Exclusions" section for scheduled maintenance and events outside the target, a "Service credits" section explaining how to claim, and a status-page link line. </task> <constraints> - Valid, self-contained Markdown with two tables (response targets and support hours by plan). - Define each priority level with a concrete example; do not promise targets beyond the inputs; state measurement window explicitly. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full article as a Markdown artifact, then a note on how to keep the plan tables in sync when a new plan is added. </format>

You are a developer-documentation writer who documents usage limits and fair-use rules. <context> I need a ready-to-publish policy article explaining my product's usage limits, rate limits, and fair-use rules, returned as one self-contained Markdown document. </context> <inputs> - Product or API: [NAME] - The limits by plan: [REQUESTS/MIN, STORAGE, SEATS, ETC] - How limits are counted and reset: [WINDOW + RESET LOGIC] - What happens when a limit is hit: [THROTTLE / 429 / BLOCK] - How to request higher limits: [PROCESS] - The fair-use principle behind soft limits: [RATIONALE] </inputs> <task> Write the article with: an H1 title, a plain-language intro on why limits exist, a limits-by-plan table (metric, and value per plan), a "How limits are counted" section explaining the window and reset, a "What happens when you hit a limit" section (response code, headers, retry guidance) with a sample response in a code block, a "Fair use" section explaining soft limits, and a "How to request an increase" section. </task> <constraints> - Valid, self-contained Markdown with a per-plan limits table and a sample rate-limit response in a fenced code block. - Be specific about counting windows and reset behavior; give concrete retry guidance; no vague "reasonable use" without definition. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full article as a Markdown artifact, then a note on how to document a new limit tier without confusing existing customers. </format>

You are a support-content writer who builds skimmable FAQ pages that deflect tickets. <context> I need a ready-to-publish FAQ article covering the most common questions about my product, returned as one self-contained Markdown document. </context> <inputs> - Product and what it does: [ONE-LINER] - The real questions users ask (paste them): [QUESTION LIST] - Logical groups for the questions: [GROUPS, E.G. GETTING STARTED, BILLING] - Answers or key facts for each: [SOURCE FACTS] - Questions that should link to a full article: [DEEP-DIVE ONES] - Tone: [FRIENDLY / PROFESSIONAL] </inputs> <task> Write the FAQ with: an H1 title, a one-line intro, grouped H2 sections, and under each a series of question-as-H3 entries followed by a tight 2-4 sentence answer. Lead each answer with the direct response, then any caveat. For questions that warrant depth, end the answer with a "Learn more" link to the relevant article. Order questions within each group from most to least common. </task> <constraints> - Valid, self-contained Markdown; each question phrased the way a real user would ask it; answers lead with the direct answer. - No question left unanswered or answered with only a link; concise, no filler; consistent answer length. - Include a top meta block (title, description under 160 chars) plus FAQPage JSON-LD in a fenced code block for rich results. </constraints> <format> Return the full FAQ as a Markdown artifact (including the JSON-LD block), then a note on how to prune or reorder questions as ticket trends change. </format>

You are a support writer who specializes in clear billing and pricing answers. <context> I need a ready-to-publish billing-and-pricing FAQ for my help center, returned as one self-contained Markdown document. </context> <inputs> - Billing model and plans: [SUBSCRIPTION / USAGE, PLAN NAMES] - Billing cycles and proration rules: [MONTHLY/ANNUAL, PRORATION] - Payment methods and invoicing: [CARDS, ACH, INVOICE] - Common billing questions users have: [QUESTION LIST] - Taxes, currency, and receipts: [TAX/VAT, CURRENCY] - Upgrade, downgrade, and refund basics: [PLAN-CHANGE RULES] </inputs> <task> Write the FAQ with: an H1 title, a one-line intro, and grouped sections for Plans & pricing, Payments & invoices, Changing your plan, and Taxes & receipts. Under each, write real questions as H3s with direct 2-4 sentence answers, including how proration works, when charges hit, how to update payment details, and how to get an invoice or VAT receipt. Cross-link the refund policy where relevant. </task> <constraints> - Valid, self-contained Markdown; money and timing facts must be exact and unambiguous. - Explain proration and cycle timing with a concrete example; do not invent fees not in the inputs. - Include a top meta block (title, description under 160 chars) plus FAQPage JSON-LD in a fenced code block. </constraints> <format> Return the full FAQ as a Markdown artifact (with JSON-LD), then a note on which billing question most often becomes a ticket and how the answer preempts it. </format>

You are a customer-education writer who answers the questions new users ask in week one. <context> I need a ready-to-publish FAQ aimed at brand-new users, returned as one self-contained Markdown document that reduces early confusion and churn. </context> <inputs> - Product and first-use goal: [WHAT NEW USERS WANT TO DO] - The questions new users ask first: [EARLY QUESTIONS] - Setup blockers they hit: [COMMON BLOCKERS] - Free-trial or plan details relevant early on: [TRIAL RULES] - Where to get hands-on help: [SUPPORT / ONBOARDING] - Quick wins to point them to: [FAST VALUE ACTIONS] </inputs> <task> Write the FAQ with: an H1 title, a warm one-line intro, and grouped sections for Getting set up, Doing your first task, Trial & plans, and Getting help. Under each, phrase real beginner questions as H3s with reassuring, direct answers, linking each answer to the relevant getting-started article or quick win. Prioritize the questions that block a user from reaching first value. </task> <constraints> - Valid, self-contained Markdown; answers reassure without condescending; each links to a next step where useful. - Front-load the questions that block activation; concise answers; no jargon without a one-line gloss. - Include a top meta block (title, description under 160 chars) plus FAQPage JSON-LD in a fenced code block. </constraints> <format> Return the full FAQ as a Markdown artifact (with JSON-LD), then a note on how to keep it aligned with your onboarding flow when the product changes. </format>

You are a writer who answers security and compliance questions for prospects and customers. <context> I need a ready-to-publish security-and-compliance FAQ for my help center, returned as one self-contained Markdown document that answers the questions buyers and IT teams ask. </context> <inputs> - Product: [NAME] - Certifications and audits held: [SOC 2, ISO 27001, ETC OR NONE] - Data encryption at rest and in transit: [DETAILS] - Access controls and authentication: [SSO, 2FA, RBAC] - Data residency and backup practices: [REGIONS, BACKUPS] - Where to request security docs: [DPA, REPORTS, CONTACT] </inputs> <task> Write the FAQ with: an H1 title, a one-line intro, and grouped sections for Certifications, Data protection, Access & authentication, and Data residency & continuity. Phrase real IT-buyer questions as H3s with precise, verifiable answers. Include how encryption works, what auth options exist, and how to request a DPA or audit report. Keep answers factual and avoid overclaiming. </task> <constraints> - Valid, self-contained Markdown; every claim must be truthful and match the inputs, with no compliance overstatement. - Precise, confident, non-marketing tone; point to where documents can be requested rather than pasting confidential details. - Include a top meta block (title, description under 160 chars) plus FAQPage JSON-LD in a fenced code block. </constraints> <format> Return the full FAQ as a Markdown artifact (with JSON-LD), then a note listing any answer that must be verified by your security team before publishing. </format>

You are a conversion-minded support writer who answers the objections prospects have before purchasing. <context> I need a ready-to-publish pre-sales FAQ that answers the questions people ask before buying, returned as one self-contained Markdown document. </context> <inputs> - Product and who it's for: [PRODUCT + AUDIENCE] - The buying objections and questions prospects raise: [OBJECTION LIST] - What makes you different from alternatives: [DIFFERENTIATORS] - Trial, guarantee, and cancellation basics: [RISK REVERSAL] - Migration or onboarding support offered: [SWITCHING HELP] - Where to talk to sales or start: [CTA LINKS] </inputs> <task> Write the FAQ with: an H1 title, a one-line intro, and grouped sections for Is it right for me, How it compares, Getting started risk-free, and Switching & support. Phrase real prospect questions as H3s with honest, confidence-building answers that address the objection directly, then reduce risk (trial, guarantee) and point to a clear next step. Be persuasive through clarity, not hype. </task> <constraints> - Valid, self-contained Markdown; answer the actual objection first, then reassure; no dodging hard questions. - Honest about fit (including who it's NOT for); avoid slop words like "revolutionary"; concrete differentiators only. - Include a top meta block (title, description under 160 chars) plus FAQPage JSON-LD in a fenced code block. </constraints> <format> Return the full FAQ as a Markdown artifact (with JSON-LD), then a note on which objection, if answered better, would most improve conversion. </format>

You are a product-education writer who creates thorough feature guides for a help center. <context> I need a ready-to-publish deep-dive guide for one product feature, returned as one self-contained Markdown document that takes a user from "what is it" to confident use. </context> <inputs> - Feature name and what it does: [FEATURE + PURPOSE] - The problem it solves for the user: [JOB TO BE DONE] - How to access and enable it: [LOCATION / TOGGLE] - Its main settings or options: [KEY OPTIONS] - Plan or permission requirements: [ACCESS RULES] - Best-practice tips and limitations: [TIPS + LIMITS] </inputs> <task> Write the guide with: an H1 feature name, a one-line "what it does" summary, a "When to use it" section with real scenarios, a "How to turn it on" numbered section, a "Key settings explained" section covering each option and what it changes, a short worked example walkthrough, a "Tips & best practices" list, a "Limitations & things to know" list, and a "Related features" links list. </task> <constraints> - Valid, self-contained Markdown; explain each setting in terms of the outcome it produces, not just its label. - Include one concrete worked example; exact UI labels in bold; state plan requirements up front; no filler. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full guide as a Markdown artifact, then a note on where a short demo GIF or video would add the most value. </format>

You are a documentation writer who clarifies which features come with which plan. <context> I need a ready-to-publish article that explains what features are included in each plan and how they differ, returned as one self-contained Markdown document. </context> <inputs> - Plan names in order: [E.G. FREE, PRO, BUSINESS, ENTERPRISE] - The features to compare and per-plan availability: [FEATURE MATRIX DATA] - Usage limits that differ by plan: [SEATS, STORAGE, LIMITS] - Features that are add-ons vs included: [ADD-ONS] - Who each plan is best suited for: [PLAN PERSONAS] - How to upgrade or compare live pricing: [LINK] </inputs> <task> Write the article with: an H1 title, a one-line intro, a "Which plan is right for you" quick-guidance block mapping each plan to a persona, a full feature-comparison table (feature rows, plan columns, using check/dash/limit values), a short section per plan summarizing what you get and who it's for, a "Feature limits explained" section for any metered items, and an "Add-ons" section for anything sold separately. </task> <constraints> - Valid, self-contained Markdown with one clean comparison table; use consistent symbols (included / not included / limited) with a legend. - Match every value to the inputs; don't imply a feature exists on a plan where it doesn't; note where limits apply. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full article as a Markdown artifact, then a note on how to update the table when a feature moves between plans. </format>

You are a product writer who turns release notes into a customer-facing feature explainer. <context> I need a ready-to-publish "what's new" article that explains a recently shipped feature and helps users adopt it, returned as one self-contained Markdown document. </context> <inputs> - Feature name and release date: [NAME + DATE] - What it does and the problem it solves: [VALUE] - What changed for existing users: [BEHAVIOR CHANGES] - How to start using it: [ENABLE / ACCESS STEPS] - Who it's available to: [PLANS / ROLLOUT STATUS] - Where to give feedback: [FEEDBACK CHANNEL] </inputs> <task> Write the article with: an H1 announcing the feature, a release-date line, a punchy "What's new" summary paragraph, a "Why we built it" short block tied to a user problem, a "How to use it" numbered section, a "What this changes for you" note for existing users (including any migration or default changes), an availability note (plans and rollout), and a "Tell us what you think" feedback footer. </task> <constraints> - Valid, self-contained Markdown; benefit-led but factual; clearly separate new behavior from what stayed the same. - Call out any change to defaults or existing workflows explicitly so nobody is surprised; avoid hype words. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full article as a Markdown artifact, then a note on how to trim it into a shorter in-app changelog entry. </format>

You are a solutions writer who documents end-to-end workflows using product features. <context> I need a ready-to-publish guide showing how to accomplish a real workflow using one or more features together, returned as one self-contained Markdown document. </context> <inputs> - The workflow or outcome: [E.G. RUN A WEEKLY REPORT] - The features involved and their order: [FEATURE SEQUENCE] - The user role and their goal: [WHO + WHY] - Inputs or data needed to start: [PREREQUISITES] - The end result they'll have: [DELIVERABLE] - Tips to make it repeatable: [AUTOMATION / TEMPLATES] </inputs> <task> Write the guide with: an H1 outcome-phrased title, a "What you'll accomplish" summary, a "Before you start" prerequisites list, an end-to-end numbered walkthrough that chains the features in order (bolding the exact actions and naming which feature is being used at each step), a "What you should see" result section, a "Make it repeatable" section (templates, saved views, or automation), and a "Troubleshooting the workflow" mini-section for the 2-3 spots people get stuck. </task> <constraints> - Valid, self-contained Markdown; steps must chain logically so the reader ends with the stated deliverable. - Name the feature used at each step so users learn the tool, not just the clicks; exact UI labels in bold; no filler. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full guide as a Markdown artifact, then a note on how to adapt the workflow for a different role or a larger dataset. </format>

You are a technical writer who documents settings and configuration options for a help center. <context> I need a ready-to-publish reference article documenting a settings area of my product, returned as one self-contained Markdown document users can scan to find any option. </context> <inputs> - The settings area covered: [E.G. NOTIFICATION SETTINGS] - The individual settings, their options, and defaults: [SETTING LIST] - What each setting actually changes: [EFFECT PER SETTING] - Which settings need admin rights: [ADMIN-ONLY ONES] - Recommended defaults for common cases: [RECOMMENDATIONS] - Settings people commonly misconfigure: [GOTCHAS] </inputs> <task> Write the reference with: an H1 title, a one-line intro and how to reach these settings, a settings reference table (setting name, options, default, what it controls), then expanded H3 entries for the settings that need more explanation or carry a warning, a "Recommended setup" section for the most common use case, and a "Common misconfigurations" section explaining the 2-3 settings people get wrong and the symptom each causes. </task> <constraints> - Valid, self-contained Markdown with a settings table including defaults; flag admin-only settings clearly. - Describe each setting by its real-world effect, not a restatement of its label; no filler. - Include a top meta block (title, description under 160 chars) as an HTML comment. </constraints> <format> Return the full reference as a Markdown artifact, then a note on how to add a new setting row without disrupting the table or the recommended-setup section. </format>