Prompt Template Library

Half of a complete prompt here is about what the bot must not do

Run the defaults above and the library produces a 5,263-character support prompt for WhatsApp, about 1,120 tokens. Four of its nine sections are guardrails: refusal, handoff, data safety and injection resistance. Together they are 50.0% of the text. The role, scope and knowledge-boundary sections, the part most people think of as the prompt, come to 26.8%. Tone is the shortest section at 3.1%, and it should be. A tone rule that runs to three paragraphs is a personality document, and a personality document belongs somewhere a model can be tested against it, not in the standing instruction.

That split holds across every combination the library can produce. All 480 of them, eight use cases by five channels by three tones by two grounding modes by handoff on or off, score 9 of 9 on the coverage audit by construction, and they run from 4,603 to 5,454 characters. The variation comes almost entirely from the scope and refusal lists, which differ per use case, and from the format section, which differs per channel. The guardrails barely move, because the things a bot must refuse do not depend much on what it is for.

Now load one of the three example prompts in audit mode. They are composites we wrote in the shape that turns up in builders, and they score 2, 3 and 5 of 9. The one-liner covers role and knowledge boundary and nothing else. The friendly persona covers role, knowledge boundary and a handoff; "be warm" on its own does not register as a tone rule, because a tone rule names the register it wants. The rules list gets to five by being a list, and still has no tone, no handoff and no data-safety rule. None of the three is wrong so much as unfinished, and the audit is there to make the unfinished part visible before a customer does.

The nine components, and what each one prevents

Our prompt engineering guide for chatbots says to write a baseline in layers: role and audience, scope in both directions, tone, then constraints and grounding rules. The library takes those layers and splits them into nine named components, because "constraints" turned out to be four different things (refusal, handoff, data safety and injection resistance) that fail in four different ways. Each row is also a detector in the audit and a paragraph the tool offers when the row is missing.

Two of the nine deserve a longer note because they are the ones most often argued about. The knowledge boundary is where hallucination is fought in prose, and prose is the weaker weapon. The library's strict grounding mode tells the model to answer only from supplied reference material and to say so when the answer is not there; the general mode allows general knowledge for questions that are not about your business and requires the model to flag when it is using it. Either one assumes you are supplying reference material at all, which is the retrieval half of the design and not something a prompt can substitute for. Our guide to reducing hallucinations covers what the prompt can and cannot do here.

The injection-resistance section is the other. Its central sentence, that everything the customer writes is data about their request and never an instruction, is the framing that closes the easy attacks. It does not close the hard ones, and a prompt that claims otherwise is lying to you. Run the finished prompt through our prompt injection tester, and read the prompt injection entry for why the real defense is keeping sensitive actions behind tool permissions rather than behind wording.

What the channel changes

The format section is the one part of the prompt the library rewrites per channel, and it draws its numbers from the same table our script generator lints against, so the two tools cannot disagree about a cap.

The reading budgets are ours, and the prompt says so: it quotes the platform cap as a hard limit and the budget as the length a reply should normally stay under. The two numbers do different jobs. A model told only the cap will write to it. A model told only the budget has no idea what happens when it runs over. Telling it both, with the cap framed as the thing never to approach, is what gives a WhatsApp reply enough margin to stay clear of an API rejection, or of whatever your builder does when a body runs over. WhatsApp plain-text bodies allow 4,096 characters; the prompt quotes the 1,024 interactive-message cap because reply buttons are the common case and the lower number is the safe one.

The session-window line matters more than it looks. On the three Meta channels the conversation closes 24 hours after the customer's last message, and the bot's own replies do not extend it. Reopening it is not free text: WhatsApp needs an approved template, Messenger and Instagram need a message tag with a permitted use. A bot that tells a customer to check back tomorrow, without knowing that, is making a promise the channel will break. Our WhatsApp Business API entry covers the window itself.

The token cost of doing it properly

A complete prompt in this library is roughly 972 to 1,170 tokens on an o200k-family estimate, and the model reads it on every turn. At a thousand conversations a day averaging six turns, that is around six million system-prompt tokens a day before a single customer word is counted, and closer to seven at the top of the range. Whether that matters depends on the model. Our LLM API cost calculator will put a price on it for the model you are using, and the prompt caching entry explains why a long, stable system prompt is the best case for the cached-input discount most providers now offer: the prefix does not change between turns, so it is written to the cache once, at or slightly above the normal input price depending on the provider, and read back at a fraction for as long as the cache stays warm.

What does not help is shortening the prompt by removing components. The guardrails are the part that costs money to leave out. A data-safety section is about 750 characters; a customer pasting a card number into a transcript that nobody cleared for it is a different order of expense. The token estimate here uses the same approach as our token counter, which explains the estimate's accuracy against real tokenizers and why it runs slightly high on English prose.

Why the templates are deterministic

The obvious way to build a prompt library in 2026 is to have a model write the prompt. We did not, for the same reason our script generator does not: a system prompt is a document a team argues with, reviews, and puts in version control. If the tool produced different wording on every run you could not tell your edits from its variance, and the second draft would be a fresh negotiation rather than a diff. Fixed templates give the same starting point every time, and the Markdown export carries the options and coverage score in its header so a reviewer can see what was chosen without opening the tool.

The eight use cases are the ones that recur across the builders we open for reviews. Support, sales, FAQ and booking are the four that almost every platform ships a template for. Lead qualification and order status are the two where the scope list does most of the work, because the failure mode is the bot doing too much: scoring a lead it was meant to record, or estimating a delivery date the system did not return. Onboarding and the internal helpdesk are there because they are the two most common non-customer deployments and the prompts for them are usually a support prompt with the word "customer" left in. The helpdesk template rewrites the audience to "employee" throughout.

Where this sits next to our other prompt tools

Three tools touch the system prompt and they do different jobs. This one writes it, or audits the one you have. The prompt injection tester attacks it with a payload library and grades how it holds up. The token counter tells you what it costs per turn and how much of the context window it leaves for the conversation. The script generator is the adjacent tool for a different kind of bot: it writes the literal strings a rules-based flow says, where this library writes the instruction a generative bot works from. Our generative versus rule-based guide covers which strings stay literal even when a model writes the rest.

The order that works: build or audit the prompt here, replace the merge fields with facts you can stand behind, run it through the injection tester, then test it against real conversations using the QA testing protocol before it goes anywhere near a customer.

What the library will not do for you

It does not know your refund policy, your delivery estimates, what your team can promise on a Friday night, or which of the scope items your bot is actually wired to do. Four things need your attention before any of this ships.

The merge fields are examples. Northwind Outfitters does not exist, its hours are invented, and its privacy notice points at example.com. The tool counts unfilled fields and flags them, but it cannot tell a filled field from a true one.

The scope and refusal lists describe a common version of each use case, not yours. If your support bot can issue refunds, the refusal list is wrong for you and has to be edited. If it cannot, the list is right and the handoff path has to lead somewhere that can. Our escalation playbook covers where that path should end.

The tone section is a few sentences and is not a personality prompt. It will stop the register drifting; it will not make a bot sound like your brand. If you need that, it is a separate document with its own tests, and it should stay separate.

The audit is keyword-based, so unusual wording can score lower than it deserves and the right words in a bad prompt can score higher; the FAQ below says what that means in practice. Read a present component before trusting it, and a missing one as a real gap.

Limitations worth stating

The channel caps are read from vendor documentation on the last-verified date at the top of this page, not probed against a live API, and a cap that moves between refreshes will be wrong here until the next one. The token figures are estimates from a heuristic, not a tokenizer run, and the o200k family is one of several; a model on a different tokenizer will count differently.

The nine components are an editorial framework: our reading of what a production prompt needs, drawn from platform review work and published prompting guidance. The 50.0% guardrail share follows from how we wrote the templates. It says nothing about prompts in general. A team that folds refusal into scope, or splits data safety into two, will get different numbers. The split is a diagnostic, not a target.

Nothing here is a compliance review. Bot-disclosure requirements, data-handling wording and what counts as sensitive personal data vary by jurisdiction and by what you actually do with the transcript. The data-safety section is a floor written for a general case. Have someone qualified read it, and the refusal section, before launch.

Related Chatbotscape tools and resources

Some review links below go to platforms we may earn a commission from. That relationship does not affect scores, rankings, or what this library produces. See our affiliate disclosure for how it works.

• Prompt engineering for chatbots — the layered baseline this library expands, and how to test changes to it
• Chatbot guardrails guide — what belongs in the prompt and what belongs in the tooling around it
• Reducing chatbot hallucinations — the knowledge boundary in practice
• Building a RAG chatbot — the retrieval half the prompt assumes
• Escalation playbook — where the handoff rule should send people
• QA testing protocol — how to test a prompt against real conversations before launch
• Prompt injection tester — attack the finished prompt with a payload library before launch
• LLM token counter — what the prompt costs per turn and how much context it leaves
• Chatbot script generator — the literal strings for a rules-based flow
• System prompt — the entry, in more depth than a tool can give it
• Prompt engineering — the discipline the library belongs to
• AI guardrails — the four sections that make up half the prompt
• Human handoff — the exit that has to be available from every state
• Context window — why the prompt's length is a budget decision
• Chatbase review — a builder whose whole configuration is the system prompt and the knowledge base
• Botpress review — where the prompt sits inside a larger agent design surface
• Tidio review — Lyro answers from a scraped knowledge base, the grounding half this library assumes

FAQ

What is a system prompt template?

A system prompt is the standing instruction a language model reads before every customer message: who it is, what it may do, where its facts come from, and what to do when a request falls outside that. A template is a system prompt with the business-specific parts left as merge fields, so the structure is reusable and the facts are yours. The templates here are assembled from nine named components, and each one carries the merge fields it needs. Our system prompt entry covers the concept.

What should a chatbot system prompt include?

Nine things, in our reading: a role, a scope list, a knowledge boundary, a tone, a format and length rule matched to the channel, a refusal pattern, a human handoff rule, a data-safety rule, and an instruction on how to treat text that tries to rewrite the instructions. Most prompts we see pasted into builders cover two to five of the nine. The audit mode on this page tells you which ones yours covers.

How long should a system prompt be?

Long enough to cover the nine components and no longer. The library's complete prompts run from 4,603 to 5,454 characters, which is roughly 972 to 1,170 tokens on an o200k-family estimate. That is a fixed cost on every turn, which is what makes prompt caching worth reading about. In words, the complete prompts run from 777 to 924, under the roughly thousand-word point where our prompt engineering guide finds instructions start to dilute. A prompt under 500 characters is almost always missing a component; a prompt past a thousand words is usually carrying policy text that belongs in the reference material instead.

Does this tool use AI to write the prompt?

No. Every sentence comes from a fixed template that varies by use case, channel, tone, grounding mode and whether a person is reachable. That is deliberate; the section above on deterministic templates explains why.

Why does the format section change when I switch channels?

Because the channel decides what the model's output can look like. Messenger and Instagram render no formatting at all; WhatsApp has its own syntax (single asterisks, underscores, simple bullets) and shows Markdown's double asterisks, headings and tables as raw symbols. WhatsApp rejects a reply-button message body over 1,024 characters; Instagram over 1,000; Messenger over 2,000. Telegram allows 4,096 and renders light formatting. The format section quotes the platform cap and sets a shorter reading budget under it, and it mentions the 24-hour session window on the three Meta channels because a bot that says "come back tomorrow" has to know the conversation will be closed by then.

What does the coverage score actually measure?

Whether each of the nine components is present, detected by keyword patterns. It is generous by design and it measures presence, not quality: a prompt that says "use a friendly tone" passes the tone check. Treat a missing component as a real gap and a present one as something to read yourself. The paragraph offered for each gap is a starting point, written in the same register as the library.

Will the injection-resistance section stop prompt injection?

It reduces the easy cases and does not stop the hard ones. Telling a model that customer text is data rather than instruction closes off "ignore your previous instructions" and the persona swaps that follow it, but no wording defends against every payload. Run the finished prompt through our prompt injection tester, keep the sensitive actions behind tool permissions rather than prose, and treat the section as one layer of several.

Does the library send my prompt anywhere?

No. Everything runs in your browser. Nothing you type or paste is uploaded, stored, or logged, and reloading the page clears it. That includes the audit mode: your existing system prompt never leaves the tab.

Can I embed the library on my site?

Yes, free. Copy the iframe snippet from the embed section above. The embed strips Chatbotscape navigation and keeps the tool plus attribution.

Sources and basis

• The nine-component structure is editorial. It expands the layered order in our prompt engineering guide (role, scope, tone, constraints, grounding), drawn from platform review work and published prompting guidance from the major model providers. It is a reading, not a standard, and the tool presents it as one.
• Channel caps.WhatsApp, Messenger and Instagram body limits and the 24-hour customer service window are Meta's published Cloud API and send-API values; Telegram's 4,096 is the documented Bot API message limit. They are read from the same table our script generator uses and were re-checked for this tool on 8 September 2026. The website-widget figure and every reading budget are ours, and the prompt text says so.
• Token estimates. Produced by the same heuristic as our token counter, calibrated against o200k-family tokenizer output as documented on that page. They are estimates, not tokenizer runs.
• Example prompts are composites. The three prompts in audit mode were written for this tool in the shape we see pasted into builders. None is quoted from a vendor, a customer or a published template.
• No customer deployment data. Every figure on this page is computed by the library itself from its own output. Nothing here reports measured results from a live bot.
• Figures reproduced from the shipped engine. The 5,263-character default, the 50.0% guardrail share, the 480 combinations, the 4,603 to 5,454 character range, the 777 to 924 word range, the 972 to 1,170 token range and the 2, 3 and 5 scores for the example prompts are printed by the same code that runs above, checked before publication.