At the time this article was prepared, the asgeirtj/system_prompts_leaks repository had surpassed 53,000 GitHub stars, reflecting strong community interest in how real-world AI products are actually built. Among the compiled documents, the claude-fable-5.md file stands out for its sheer scale — broken into multiple clearly structured sections rather than the short, single-paragraph prompt typically seen in chatbot demos.

This article does not attempt to verify the authenticity of the leaked prompt, nor does it treat it as an official Anthropic document. Instead, the file is used as a case study for observing how a large-scale AI product organizes its system prompt: defining the assistant's role, specifying behavior, describing context boundaries, setting tool-usage policy, laying out safety requirements, and defining the output contract.

The real lesson here isn't the specific wording of any given instruction — it's how the system prompt is designed as an architecture. Rather than simply telling the model "how to answer," it consolidates a wide range of product, UX, and operational decisions into a single, unified document — one that can be extended, reviewed, and tested over time.

1. Why shouldn't every rule live in one single file?

An AI project usually starts with a very short prompt: You are an internal assistant. Answer clearly and helpfully.

At first, the product team adds tone-of-voice guidance. Then the backend team adds tool-usage rules. Security adds rules for protecting secrets. UI requires JSON output. Each addition is just a few lines, so no one notices a problem forming.

Over time, the prompt file can grow to hundreds or even thousands of lines. When it's time to edit a section, the team runs into three hard questions.

First question: who should review this change? Product understands user experience, backend understands tooling, and security understands access control. A single file that contains everything blurs ownership.

Second question: what needs to be re-tested? If you only change how the AI asks for confirmation before deployment, you shouldn't necessarily need to re-test every question about tone. But in a monolithic prompt, the blast radius of a change is nearly impossible to see.

Third question: which requests actually need all these rules? A request that simply reads logs may not need the full set of instructions covering deployment, sending email, or JSON output.

The fix isn't to split every paragraph into its own file. The fix is to group rules that share a common purpose into a module — where "module" simply means a section of the prompt that owns one clear responsibility.

2. Six layers of responsibility that can be extracted from the Fable prompt

Identity: who is this assistant, really?

Identity defines what kind of assistant the product is offering, who it serves, and where its capability boundaries sit. If an application only has permission to read tickets, the model shouldn't talk as if it can already access production or restart a service.

Good identity design isn't a long persona description. It's a capability boundary clear enough that the model never claims more than what the system can actually do.

Behavior: how should the conversational experience operate?

Behavior answers questions like: should the short answer come before the explanation, or vice versa? When should the model ask a follow-up question? When should it separate fact from hypothesis? And when should it avoid slowing the user down with too many questions?

This isn't just tone of voice. Behavior directly shapes UX and how users make decisions based on the response they receive.

Context boundary: what counts as an instruction, and what's just evidence?

An assistant may read user input, uploaded files, websites, memory, tickets, and tool output. These sources don't carry equal trust. Content pulled from the web or a file might contain a phrase like "ignore previous instructions" — but it's still just data to be analyzed, not a new command.

The context boundary helps the model distinguish policy from untrusted content, while also prompting it to cite sources, flag conflicts, and avoid letting retrieved data masquerade as a new instruction.

Tool/action policy: what is the assistant allowed to propose and execute?

Tool policy separates read-only operations from actions with side effects. Reading logs is different from restarting a service. Drafting an email is different from sending one. Suggesting a SQL query is different from running a migration.

The prompt needs to spell out which actions require confirmation, what scope must be shown to the user, and how rollback should be described. That said, actual permission enforcement still has to live in the backend.

Safety: where does the system need to stop or exercise extra caution?

Safety covers credentials, personal data, authorization bypass, and changes with a large blast radius. A useful safety module doesn't just say "be safe" — it ties specific risks to specific behaviors: redact secrets, refuse to bypass permissions, or require a verification signal before a production change.

Output contract: how will the backend actually use the response?

If the response is only ever shown to a human, Markdown may be enough. If the response feeds into a workflow, a UI, or a tool router, the output needs a clear contract: JSON keys, real booleans instead of strings, required fields, and a defined way to represent unknown data.

Fable-style layerProject moduleKey review question
Identityidentity.mdWho is the assistant, and which capabilities must it never claim?
Behaviorbehavior.mdWhen should it answer directly, ask a follow-up, or separate fact from hypothesis?
Context boundarycontext-boundary.mdWhich sources are policy, which are the request, and which are untrusted evidence?
Tool/action policytool-policy.mdWhich actions carry side effects and require confirmation?
Safetysafety.mdHow are secrets, authorization, and production risk handled?
Output contractoutput-contract.mdWhat format must the response follow so downstream systems can use it?

3. Applying this structure to an AI project

A minimal structure that's practical to adopt might look like this:

ai-project/
  prompts/
    modular/
      identity.md
      behavior.md
      context-boundary.md
      tool-policy.md
      safety.md
      output-contract.md
    manifest.yaml
    profiles/
      read-only.yaml
      action-enabled.yaml
      structured-output.yaml
  evals/
    cases.yaml
  src/
    prompt_compiler.py
    guardrails.py

The manifest locks in the order in which modules are assembled:

modules:
  - identity
  - behavior
  - context-boundary
  - tool-policy
  - safety
  - output-contract

The compiler only needs to read the list, check for missing/duplicate/out-of-order modules, and then concatenate the text. The key requirement: the same source must always produce the same compiled prompt, and the prompt version should be logged per request.

modules = self.profile_modules(profile)
parts = []
for module in modules:
    path = self.prompts_dir / "modular" / f"{module}.md"
    parts.append(path.read_text(encoding="utf-8").strip())
compiled_prompt = "\n\n".join(parts)

the-fable-structure-diagram

The Fable structure broken into six prompt files, reassembled, and passed through the guardrail layer 

A module only has value when it comes with an owner and an eval

Product can review identity.md and behavior.md. Backend reviews tool-policy.md and output-contract.md. Security focuses on context-boundary.md and safety.md. This split doesn't remove the need for cross-review, but it gives each team a clear starting point.

Evals should map to modules the same way. When context boundary changes, CI should prioritize running indirect-prompt-injection and source-conflict cases. When the output contract changes, CI should run JSON-validity and required-key checks. At that point, module boundaries become test boundaries, not just a way of organizing folders.

Benchmark: the runtime cost of three prompt architectures

A demo compared three approaches (github.com/Keruedu/Demo-Fable-system-prompt):

  • monolith: every rule lives in a single file.
  • modular-full: all six files are reassembled in full.
  • modular-profiled: only the files needed for the current task type are assembled.

The demo repo compares monolith, modular-full, and modular-profiled. To make the comparison valid, an offline check confirms that the two full versions have identical normalized content and the same SHA-256 hash. The actual benchmark then runs SmolLM2-135M-Instruct in Q4_K_M quantization through llama.cpp: 25 cases, three variants, one pass per case, for 75 records total.

token-benchmark-chart

Actual input token counts reported by llama.cpp for the three prompt variants

The percentage reduction is calculated as follows:

(671.16 - 477.76) / 671.16 x 100 = 28.82%

The first two variants both come in at 671.16 tokens, since the content sent to the model is identical — splitting one file into six doesn't reduce token count on its own. The third variant drops to 477.76 tokens because it only pulls in the modules the current task actually needs.

These token counts come from the usage.prompt_tokens field returned by llama.cpp. They include the system prompt, the user's question, the chat template, and the retry pass on cases that require JSON output.

4. The prompt is the house rules; the guardrail is the lock on the door

This is the most important boundary to keep in mind when applying a Fable-style structure in production.

tool-policy.md can require that the model never deploy without confirmation — but the backend still has to block the deploy API when there's no approval token. context-boundary.md can state that uploaded files are untrusted content — but the ingestion pipeline still has to tag sources and keep raw secrets out of the prompt. output-contract.md can require JSON — but the application still has to parse and validate that output against a schema before using it.

Prompt moduleAccompanying guardrail or test
identity.mdCapability registry and tests against fabricated actions
context-boundary.mdSource labeling, sanitization, and injection evals
tool-policy.mdPermission checks, confirmation gates, and idempotency
safety.mdSecret redaction, authorization, and audit logging
output-contract.mdJSON schema validation and retry/fallback policy

The prompt is a soft control, because the model can misunderstand it or fail to follow it. The backend guardrail is a hard control, because an invalid request has to be rejected regardless of what the model says.

That's also where the trade-off of a modular architecture shows up. The project now needs a compiler, a manifest, profiles, and eval mapping. If a team doesn't have CI yet, or the prompt is still very short, a monolith may well be enough. Once the prompt has multiple owners, tools, and contracts, the cost of this extra structure starts to pay for itself.

5. The system prompt is part of the product's architecture

The prompt reportedly leaked from Fable is interesting not because it contains a single instruction you could copy into any chatbot. What it shows is that the system prompt of a large AI product has grown to hold multiple layers of decisions at once: identity, behavior, context boundary, action policy, safety, and output contract.

In practice, these layers should be split into separate modules, each with its own owner and eval, then assembled through a defined process. A profiling layer should only be added once a benchmark actually proves it's worth the cost. In the end, the prompt only guides the model, evals check its behavior, and every permission and validation that actually matters still has to be enforced by the backend or the guardrail.

References

TagTutorialAl/MLModel as a Service