Reading the Archive: Surfaces, Versions, and Evidence
For the asgeirtj/system_prompts_leaks repository, the central reading problem is classification: a prompt file means different things depending on the product surface, mode, date, and capture history behind it. This chapter develops that problem so readers can decide what a file describes, how much confidence to place in it, and which details are worth carrying into a comparison.
The archive is large enough to invite the wrong first move. A reader can scan model names, open the longest file, and begin collecting striking instructions. That approach produces vivid anecdotes but weak understanding. It treats every file as the same kind of object and every difference as a model difference. The repository’s own organization points to a better method. Before interpreting a prompt, identify the product that uses it, the work that product supports, the version or date involved, and the strength of the evidence for its origin.
Start with the surface, not the model name
A model is a capability layer. A product surface is the setting in which that capability is offered. The distinction is easy to state and easy to ignore. A general chat application may need a persona, response style, image behavior, and broad safety rules. A coding agent may need file access, shell execution, workspace context, permission checks, and a duty to report what actually happened. An API prompt may assume that a developer, rather than an end user, supplies tools and controls the surrounding application. These surfaces can share a model family while requiring very different instructions.
The repository’s catalog makes those differences visible across providers. It places ordinary chat prompts beside coding-agent prompts, tool prompts, modes, personalities, integrations, and API-oriented entries. The Anthropic catalog is especially explicit. It distinguishes bare model files for the Claude web or mobile application from the Claude Code directory, separate no-tool variants, integrations, injected fragments, and official releases. The point is not the directory layout itself. The point is that a model label does not identify the complete behavior contract.
Consider a simple question such as, “Can this assistant change a file?” The model name may not answer it. A coding product can be instructed to inspect a workspace, use an edit operation, verify the result, and report a failure. A chat product using a related model may have none of those tools. A connected workspace may be able to edit a document only after an account connector is enabled. An API caller may have to supply the tool and implement authorization in its own application. The meaningful comparison is therefore between surfaces and control paths, not between names in a catalog.
The same rule applies when a file is described as a no-tool or API variant. Those labels are not minor metadata. They change the set of actions the assistant can take, the evidence it can retrieve, and the risks created by a wrong decision. A no-tool prompt may describe how to answer without external operations. A tool-enabled prompt must also define when the assistant should invoke a capability, what information crosses the boundary, and how the result enters the answer. An API-facing prompt may describe a protocol that only becomes real when a developer supplies matching tools.
A useful classification asks four questions:
- What product is this? A chat app, coding agent, search service, integration, browser tool, or API layer?
- What mode is represented? A model variant, agent mode, personality, plan mode, no-tool mode, or injected fragment?
- What work does the surface authorize? Conversation, retrieval, file changes, connected-service actions, or structured rendering?
- What is the capture boundary? A whole prompt, a fragment, a tool description, a shortened official release, or a repository summary?
These questions keep a reader from treating an API tool description as a complete assistant persona or a dynamic warning as the product’s permanent system prompt. They also prevent a more subtle mistake: assuming that a prompt file is the only instruction the model receives. The archive can classify what it retains. It cannot, from classification alone, show that no other runtime layer exists.
Dates turn files into snapshots
Once the surface is identified, date becomes the next essential dimension. A prompt is not a timeless description of a model. It is a capture associated with a release, an account, a mode, or a moment in a changing product. The repository’s README records additions dated across July, August, and September 2026, including new Claude, Codex, Gemini, Grok, and other captures. It also preserves versioned names and variants. That makes the collection useful for observing change, but it does not turn it into a complete product history.
Date metadata answers one question: when did the archive say this item was added or current? It does not automatically answer when the originating service began using the text, how long it remained active, whether a later capture replaced it, or whether the file was edited after capture. Those questions require stronger provenance. A careful comparison should align at least the product surface, model or mode, and date before interpreting a difference.
Suppose two files both refer to a coding agent but one contains a stronger emphasis on permission and another adds a new tool. Several explanations remain possible. The model may have changed. The host application may have changed. A feature may have been enabled for one account. The files may describe different execution modes. The archive may have received one capture later than the other. Without aligned metadata, calling the difference a model upgrade is an attractive but unsupported shortcut.
The word “version” also needs restraint. A filename can identify a model release or a product mode, but it does not guarantee that all surrounding layers share that version. A connector, client parser, safety classifier, or tool server can change independently. Conversely, a prompt can remain stable while the runtime around it changes. The useful claim is narrower: version labels help readers locate a snapshot in the archive and formulate a better comparison. They do not prove a synchronized system-wide release.
This matters for the archive’s newest entries as well as its older ones. A recent addition may be more relevant to a current question, but recency is not the same as authenticity or completeness. A current-looking file can still be partial. An older file can still reveal a durable design pattern. The reader’s task is to use date as a boundary on claims, not as a substitute for evidence quality.
What “captured verbatim” can establish
The repository presents its files as leaked system prompts captured verbatim. That description is useful because it tells readers what kind of material the maintainer intends to preserve: prompt text rather than a high-level summary. It is not the same as a vendor guarantee. In the inspected material, the repository does not provide a vendor-signed chain of custody or an independent validation process for every file. The license makes the collection reusable but also states that the work is offered as-is, without warranties about accuracy or the absence of errors.
The correct response is neither automatic trust nor automatic dismissal. Treat the repository as strong evidence of what its own current files contain. Treat it as more limited evidence of what an originating vendor deployed, when the vendor deployed it, and whether the file is complete. A file can be genuine and still omit dynamic reminders, account-specific context, host-side permissions, or later runtime changes. It can also be labeled correctly at the product level while representing only one mode or one capture route.
This distinction becomes clearer when claims are separated by object. “The repository lists a Claude Code prompt” is a claim about the catalog. “The captured text tells the assistant to report observed outcomes” is a claim about that file. “Claude Code always verifies every change” is a claim about live behavior and requires runtime testing or independent evaluation. “The vendor’s safety architecture works” is stronger still because it concerns performance, not just stated rules. The first two may be supported by the archive. The latter claims need additional evidence.
The archive’s license is relevant here for an unexpected reason. Its no-warranty language is not evidence that a particular prompt is false. It is a reminder that public availability, legal reuse, factual accuracy, and vendor endorsement are separate questions. A public file can be valuable for research even when its origin is uncertain. A license can permit reuse without guaranteeing that every upstream right has been cleared. Evidence quality and reuse conditions should not be collapsed into one judgment.
The phrase “captured verbatim” should therefore be read as a provenance statement with a boundary. It describes the intended relation between a file and the material observed by the collector. It does not establish the full relation between that file and the live product. To strengthen a material claim, a reader would look for corroboration from an official release, a second independent capture, a reproducible runtime observation, or documentation that identifies the same surface and time period.
The discipline of reading absences
An archive also teaches through what it says is missing. The GLM entry states that the relevant chat service has no system prompt and that the API does not inject one behind the scenes. This is an explicit absence claim, not merely an empty file or a provider omitted from the catalog. It challenges the assumption that every AI product must expose a long natural-language instruction layer.
The claim is useful precisely because it is bounded. It supports the statement that the repository documents an absence of a system prompt in those contexts. It does not prove that the service has no control logic. A product may still use classifiers, routing rules, permissions, model-specific defaults, safety middleware, or client-side constraints that are not represented as a visible system message. “No system prompt” can mean no natural-language message in a particular layer. It should not silently expand into “no product policy.”
The same discipline applies when a file is absent from a directory. Absence from the archive can mean that the maintainer did not capture it, that the item belongs under another product category, that the file was removed, or that the product does not expose a corresponding prompt. A partial extract cannot establish that a feature does not exist merely because the extract does not mention it. The strongest negative claims require direct evidence of the relevant boundary.
This is why classification is more than housekeeping. It determines which negative inferences are safe. If a file is labeled as a fragment, its silence about tools says little about the full assistant. If an entry is a product README that documents no prompt, it supports an absence claim but not a complete architecture. If a file is a shortened official release, its omissions may be deliberate. The object being read sets the meaning of what it does not contain.
A reader who follows this method will make fewer dramatic claims, but the resulting analysis will be more useful. They can say that the archive records a documented no-prompt case, that a capture is limited to one surface, or that a date table does not provide a full history. Those statements travel well across versions and are easier to test than a sweeping claim about how an entire vendor’s system works.
From catalog to comparison
The best use of the repository is not to memorize which provider has the longest prompt. It is to compare design choices on shared dimensions. What role does the assistant receive? What actions can it take? What state can it consult? When must it search? What requires permission? How does it report failure? Which output formats must a client parse? What is static, what is conditional, and what belongs to the host application?
Those questions let a reader connect a prompt to practical judgment. A coding agent deserves closer attention to workspace boundaries and outcome reporting because it can create durable side effects. A search-oriented assistant deserves closer attention to freshness and source handling because its value depends on retrieval. A connector-rich product deserves closer attention to user choice and data scope. A rendered assistant deserves closer attention to syntax and parser constraints. The comparison becomes meaningful because each dimension is tied to a product responsibility.
The archive’s scope also argues against exhaustive quotation and file-by-file tours. Long prompt text can make a chapter look thorough while hiding the mechanism that matters. A reader usually needs one representative rule, the condition that activates it, the boundary it protects, and the uncertainty that remains. The rest belongs in the source for readers who need implementation-level detail. The repository is a map; the goal is to understand the terrain.
The durable conclusion is simple. Before asking what a prompt says, ask what kind of object it is. Identify the surface, mode, date, and provenance. Then separate what the repository records from what the file specifies and from what the live product does. That sequence turns a collection of hidden instructions into evidence that can support careful comparison.
The next question is structural: once a prompt has been correctly classified, what recurring layers should a reader look for inside it? The answer begins with the product contract that gives an assistant its identity, style, boundaries, state, and output obligations.