Before the First Message: What a System Prompt Actually Is
The subject of this series is the asgeirtj/system_prompts_leaks repository, a public archive of captured instructions used by AI products before a person sends an ordinary message. This opening asks what those instructions are evidence of, why they matter to users and builders, and where their explanatory power stops.
A person opens a chatbot and sees a blank input box. That interface suggests a simple relationship: the person asks, the model answers. The repository makes the relationship look different. Before the visible exchange begins, a product may already have assigned the assistant a role, set expectations for tone, connected tools, defined what counts as a risky request, supplied a date, or specified how an answer must be rendered. Those instructions do not replace the model. They shape how a general capability is turned into a particular product.
That distinction matters because the same model family can appear as several different systems. In the repository’s catalog, a vendor’s general chat prompt sits beside a coding-agent prompt, an API-oriented prompt, an integration prompt, a no-tool variant, or a fragment injected only under certain conditions. A model name alone cannot tell a reader whether the assistant can edit files, search the web, remember past conversations, call a connected service, or produce a structured widget. The surrounding product surface determines much of that behavior.
The hidden layer is part of the product
A system prompt is best understood as a product contract written in natural language. It can define who the assistant is supposed to be, how it should relate to the user, what kind of work it should perform, and what it should say about its own actions. The Claude Code captures, for example, describe an agent that works inside a harness, uses tools, and reports observed outcomes rather than claiming success merely because an action was intended. The Codex capture describes a shared workspace, permission decisions, continuing authorization, and a collaborator’s working style. These are operational commitments, not just personality traits.
Other captures reveal the same layer in different forms. Perplexity’s prompt emphasizes teaching, response structure, tone, and personalization. Gemini’s prompt devotes substantial attention to direct answers, formatting, search, images, interactive components, and the rules of a streaming syntax. A Copilot agent prompt places a tight limit on routine response length and directs how the assistant should search and validate code. The differences are significant, but the pattern is common: the product uses instructions to narrow a broad model into a recognizable working role.
That narrowing creates visible consequences. A coding agent must decide whether a request implies a file change, whether permission is needed, and how to report a failed command. A search-oriented assistant must decide when remembered knowledge is too old and when retrieval is necessary. A connected assistant must decide whether a named service may be called directly or whether the person must first choose it. A rendered interface must produce output that a client parser can safely interpret. In each case, the prompt helps specify the boundary between what the person asks and what the product is authorized or able to do.
The prompt therefore sits between several components. The model supplies general language and reasoning ability. The product prompt supplies role and policy. The runtime supplies tools, context, permissions, and often additional dynamic instructions. The client turns the result into text, a file, an image, or an interactive component. User-visible behavior emerges from their interaction. Reading the prompt is valuable because it exposes one important boundary in that system. It is misleading only when the boundary is mistaken for the whole system.
What the archive puts in view
The repository’s first contribution is not any individual prompt. It is the act of placing unlike product surfaces in one comparative catalog. Its README groups captures from many providers and distinguishes general assistants from coding tools, APIs, integrations, modes, personalities, and older versions. The Anthropic section makes the problem especially clear by separating Claude app prompts from Claude Code, integrations, injected fragments, and other variants. This organization turns a collection of text files into a map of product roles.
That map changes the question a reader should ask. Instead of asking, “What is the system prompt for this model?” ask, “Which product surface is this capture describing, what work does that surface support, and what instructions make that work possible?” A web assistant, an API call, a coding harness, and a browser extension may share a model family while exposing different tools and different obligations. Comparing them as if they were one product hides the very design choices the archive makes visible.
The archive also turns time into part of the evidence. Its catalog records versioned names and date-stamped additions. A prompt captured in one release is a snapshot of a moving product, not a permanent definition of the vendor. Date and version labels help explain why two apparently similar files differ, but they do not provide a complete history by themselves. A reader should align the surface, model or mode, and capture date before attributing a change to a provider’s strategy or to a new model.
The repository’s own language supplies another important qualification. It describes the files as leaked or captured verbatim, which is a claim about their origin and fidelity. The material inspected here does not provide a vendor-signed chain of custody or an independent validation method for every file. The license makes the collection reusable but also offers it as-is and disclaims guarantees of accuracy or freedom from error. That does not make the archive useless. It tells readers what kind of usefulness to claim: the repository is strong evidence of what it records, but weaker evidence of what a live vendor system must currently contain.
A prompt is a boundary, not a mind
This boundary is easy to lose because some captures are enormous. A long file may contain tool schemas, output formats, examples, safety rules, memory instructions, connector policies, and API guidance. Its detail can create the impression that it explains every response. It does not. The file may omit a classifier, a hidden middleware layer, a tool server, an account-level permission, a retrieval system, or a post-processing step. It also cannot reveal model weights or tell us exactly how much any one instruction contributes to a response.
The distinction is practical. If a captured file says that an assistant should verify a file change before reporting it, the reader can reasonably say that the product’s declared contract values observed outcomes. The reader cannot say, from the text alone, that every change is always verified or that the runtime cannot bypass the rule. If a file specifies a search threshold, the reader can identify an intended freshness policy. The reader still needs runtime observation or independent evaluation to know whether search is invoked reliably and whether the returned evidence is correct.
An explicit absence can be just as instructive. The repository’s GLM entry says that the relevant chat service and API inject no system prompt. That is different from an empty file, and it is useful as a counterexample to the assumption that every product exposes a large natural-language instruction layer. Yet the statement remains a repository-documented claim. It does not, by itself, prove that no hidden control logic, classifier, or host-side policy exists elsewhere. “No captured prompt,” “the archive says no prompt,” and “the product has no control layer” are three different conclusions.
This is why the central theme of the series is not prompt secrecy. It is prompt architecture. The archive lets readers see how products express identity, authority, search, state, safety, and presentation in a layer that was previously difficult to inspect. It also teaches a discipline for interpreting that visibility. Every conclusion should name its object: the repository records something, the captured file specifies something, the originating product may intend something, or a live runtime demonstrably did something. Those claims are related, but they are not interchangeable.
Why comparison matters
A single prompt can show what one product says about itself. A comparative archive shows how product priorities become operational differences. Claude Code and Codex foreground workspaces, tools, permission, and verification because their products act on user environments. Perplexity foregrounds research-oriented response structure and personalization because its product relationship centers on information seeking. Gemini exposes a rich rendering and multimodal contract because its assistant is also a client for images, widgets, and structured output. Grok puts broad safety and override resistance near the top of its captured rules. Copilot emphasizes concise coding assistance and efficient tool use. These observations describe declared design emphasis, not a universal ranking.
Comparison also prevents a common mistake: treating safety, memory, or tool access as single features. A product’s safety boundary may be distributed across a base prompt, a tool-specific rule, a copyright policy, and a conditional reminder triggered by a classifier. Its memory may combine current conversation, stored preferences, past-chat retrieval, workspace files, and connector data. Its tool capability may depend on both a prompt instruction and a host permission. The archive is most useful when readers follow those relationships rather than count features.
The practical judgment is therefore modest but powerful. System prompts are a window into product architecture. They reveal what a product asks the model to prioritize, which actions it considers ordinary or exceptional, how it frames uncertainty, and which interface contracts it must honor. They do not provide a complete audit of the product, and they should not be used to infer a vendor’s entire philosophy from an isolated sentence. Read with those limits, the repository turns an invisible prelude into evidence that users, developers, and researchers can reason about.
The next step is to learn how to read the archive itself: how to separate app, API, agent, integration, and injected-fragment captures; how to use versions and dates; and how to distinguish a repository claim from independent authentication. That classification is the foundation for every later comparison.