System Prompt Library

Battle-tested system prompts for every role and use case

A curated, filterable library of ready-to-use system prompts for coding assistants, customer-service bots, tutors, analysts, writers, and more. Filter by role and output style, then copy any prompt to your clipboard. Runs locally. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is a system prompt?

A system prompt (also called a developer message) is the instruction set that defines the assistant's role, tone, constraints, and output format for an entire conversation. It is more durable than a single user message and shapes every reply the model gives.

System prompt library

A good system prompt does most of the work: it fixes the assistant’s role, tone, boundaries, and output format before the user ever types a word. This library collects clean, reusable system prompts across the roles teams reach for most — coding helpers, support bots, tutors, analysts, writers, researchers — so you can start from a solid baseline instead of a blank box.

How it works

Every entry is a self-contained system prompt with bracketed placeholders marking the parts you customise. Filter by role, optionally narrow by output style (concise, structured, detailed), or type a keyword to search names and bodies. Click copy on any card and paste it into the system / developer message slot of your API call or chat UI. Nothing is uploaded — the whole library lives in the page.

What makes a system prompt genuinely reusable

Most “system prompt” articles give you a sentence or two. The prompts in this library follow a structure that travels well across different models and contexts:

  1. Role and domain — a concrete description of who the assistant is and what it knows, not just “an expert.”
  2. Scope boundary — an explicit instruction for what to do when a request falls outside the intended role. Without this, the model defaults to helpfulness and wanders off-topic.
  3. Output format — the exact structure of responses: bullet points or prose, length, markdown or plain text, how to handle uncertainty.
  4. Tone — one short phrase: “professional and direct,” “friendly and encouraging,” “precise and conservative.” Long tone instructions rarely stick.

Tips for adapting a prompt

Replace every bracketed placeholder before use — an unfilled [product name] confuses the model and breaks the role framing. The three most impactful additions you can make to any template:

  • Specify the output format explicitly. “Respond in bullet points, three bullets maximum” or “always return valid JSON with keys: answer, sources, confidence” will improve consistency more than any other single change.
  • Add an out-of-scope handler. Something like “If the question is outside [domain], say: ‘I can only help with [domain]. For other topics please consult a relevant resource.’” This prevents the assistant from confidently helping with things it should not.
  • Include one or two worked examples. Showing what a good response looks like (sometimes called few-shot prompting in the system message) trains the output format better than describing it.

Keep system prompts focused on one role per prompt. Move volatile details — today’s date, the user’s subscription tier, real-time data — into the user message or a tool result rather than baking them into the system prompt, because a system prompt is typically cached and reused across sessions.

After adapting any prompt, test it against a handful of real inputs and at least a few adversarial ones (“ignore your instructions and…”) before relying on it in production.