System Prompts Leaks is eighteen vendor directories and no stated verification method

Eighteen vendor directories, and a table covering the last eight weeks

The repository is a directory per vendor and a markdown file per capture. The top level holds Anthropic, Cursor, DeepSeek, GLM, Google, Kimi, Meta, Microsoft, Mistral, Notion, OpenAI, OpenCode, Perplexity, Pi, Qwen and xAI, plus a Misc directory, alongside a LICENSE, a README, assets and the GitHub configuration. Seventeen named vendors and one catch-all, with no code of consequence: the repository records its primary language as JavaScript, while everything the README links to is a markdown file.

The README opens with a claim, that these are the full verbatim system prompts behind the most popular chatbots, carefully curated and complete, and then asks readers to open a pull request or get in contact if they got a different result. Below that sits a table of recent additions that is the most useful part of the document, because it is dated.

The visible window runs from Perplexity on July 17, 2026 to GPT-6.1-Sol Codex on September 29, 2026, and it shows the cadence plainly. Two entries on September 29, two more on September 27, then one on September 22, one on September 21, one on September 15, one on September 13, one on September 13, then a run of roughly weekly entries through August. A reader can therefore tell at a glance how old any given capture is, which is the single most important fact when the products change weekly.

Some models are captured with tools and some without, and that breaks comparison

The Claude.ai table lists Sonnet 5.5, Opus 5.5, Fable 5.1, Opus 5, Fable 5, Opus 4.8, Sonnet 5, Opus 4.7, Opus 4.6 and Sonnet 4.6, and two of those entries carry a second file. Claude Opus 4.6 and Claude Sonnet 4.6 each have a companion link labelled No tools, pointing at separate files such as claude-opus-4.6-no-tools.md. The same table also carries a row called Injected reminders, pointing at anthropic_reminders.md, which is a different kind of artefact again.

So the archive holds at least three kinds of thing under one heading: a prompt with its tool definitions, the same model's prompt without tools, and a set of reminders the product injects into a conversation rather than declaring once. Those are not interchangeable, and the README does not explain the difference between them or say which capture conditions apply to the entries that have only one file.

That is the practical limit on comparative work. If you want to know how two assistants differ in their instructions, the archive can get you close, but you have to check per file whether tools were present, and a surprising share of the entries give you no way to tell. Any analysis that lines up two prompts side by side without checking capture conditions is comparing a prompt plus a tool catalogue against a bare prompt.

The invitation to send a different result is the admission that captures disagree

There is no documented capture method, no extraction script, no session transcript, and no statement anywhere in the README about how a file was obtained or how it was checked. What there is, in one line, is an invitation: feel free to open up a PR or get in contact if you got a different result.

Read carefully, that sentence defines the project as a best-effort collection rather than a verified one. It also implies the curator expects disagreement, which is the correct expectation for this kind of material, because a system prompt is assembled at runtime from several sources, varies with account tier and feature flags, and changes without a version number. A capture is a snapshot of one session by one person.

None of that makes the archive less valuable. It changes what it can be used for. A file here is a good source for the shape of a prompt: what the system tells the model about its role, its tone, its tool conventions, its refusals, the shape of its output. It is a poor source for the exact wording, and a worse source for a claim of the form this product's prompt says X, because a different session on a different day may have produced a different document. Treat every file as one observation, cite the date from the additions table alongside the quote, and verify anything load-bearing against the live product.

CC0-1.0 is the curator's dedication, not a grant from the vendors

The repository carries a LICENSE and the licence recorded for the project is CC0-1.0, the public domain dedication. That is the most permissive licence available and it removes friction from reuse: no attribution is required, no share-alike condition applies, and a file can be copied into your own notes, a test fixture or a training set without clearing anything first.

What the dedication settles is the curator's own position in the text. It does not settle anything about the vendors whose products the text was extracted from, and those companies publish terms of service that the archive does not reproduce, discuss or interpret. The README contains no disclaimer, no legal note and no statement about permission, only the CC0 file and an invitation to contribute.

Practically, the distinction matters in one direction more than the other. Using this material to study prompt design, to write articles about it, or to build a test corpus is unencumbered by anything in the repository. Redistributing the vendors' system prompts as a product, or offering them as a service, is a question the licence in the repository does not answer. If that is your use case, the CC0 file is not the thing to rely on, and nobody in this project is going to tell you otherwise.

The Claude Code set is the deepest, and it captures the app, not just the model

Within the Anthropic directory the structure is finer-grained than a flat model list, and it is the most interesting part of the archive. The Claude Code table treats the application and the model as separate dimensions: Claude Code system prompts are listed for Opus 5.5, Fable 5.1, Opus 5, Fable 5, Opus 4.8 and Sonnet 5, and the same product is broken out by delivery surface as well, with separate files for the desktop app on Fable 5.1 and Fable 5 and a separate file for headless on Fable 5.1.

The non-prompt captures are more interesting still. One entry is an Advisor tool with the label both sides, which is a rare thing to see published: two prompts for one tool, the one the assistant receives and the one it is expected to produce. Another is Claude Cowork with what the README calls a new capture plus setup skills, linking a directory rather than a file. Claude Design is listed with its prompt and then 53 tools, 22 skills and 10 starter components, each linked as its own directory.

That granularity is what makes this repository worth more than a prompt dump. A tool definition, a skill file and a system prompt are three different kinds of artefact with three different lifetimes, and a repository that separates them lets you see how a coding agent's behaviour is assembled. The cost is that the deeper directories are organised by capture rather than by concept, so finding the pattern across products means reading a lot of files by hand.

Two newsroom projects are the only outside validation mentioned

The README names two third parties that built something on the files. The first is The Washington Post, which built an interactive story on prompts from the repository, linked through an archive copy dated May 11, 2026 and titled around the hidden rules behind AI and rewriting an article with them. The second is CEPS' AI World, which built a live data dashboard from the repository's files, dated July 10, 2026, on what system prompts reveal about a chat before the chat happens.

Two independent organisations putting published work behind the material is real evidence, and it is more than most comparable archives can point to. It also tells you something about the intended use. A newspaper interactive and a policy dashboard both need the same two things: text that is accurate enough to quote and a structure a non-programmer can browse. The second requirement is what the per-vendor directory layout and the dated additions table are for, and it is a reasonable design choice for a research archive that expects to be read as much as parsed.

What neither citation supplies is verification. A newsroom that publishes an interactive will check the quotes it uses against the product, and that checking happens on their side, not in this repository. So the archive has borrowed credibility rather than earned it, which is fine for a reader who knows to do their own checking and unhelpful for one who assumes a published citation means the file is authoritative.

The first thing in the README is a link to the author's own product

Above the title and above the press citations, the README opens with a promotional block for something called Open Source Agent Analytics, described as understanding your agents in production, with the link pointing at go.asgeirtj.workers.dev, a subdomain of the author's own domain rather than a product page on a separate service.

It is one small block, and sponsorship or self-promotion in a README is unremarkable. It is worth naming because of where it sits. The reader arrives looking for a dataset and meets a sales pitch first, then two press citations, then the claim of being carefully curated and complete. Nothing in the document marks which parts are curation and which are promotion, and a reader skimming for provenance will find the author's commercial interest above the provenance.

The discount is that the rest of the README is short and factual. The additions table is dated, the directory layout is visible in one line, the model tables are explicit about what has a No tools variant and what does not, and the project is updated close to daily with a last push on 2026-09-27. Read past the first screen and the document is honest about its own shape. It simply asks you to swallow the advertisement before the dataset.

Editorial conclusion

This archive is worth your time if you are writing prompts, reviewing a chatbot's behaviour, or writing about how commercial assistants are configured, because the files are plain markdown, organised per vendor and per model, and updated close to daily. It is the wrong source for anything where accuracy of a quote matters, because no capture method, no session context and no verification step is documented, and the curator's own invitation to open a pull request if you got a different result is an admission that captures disagree. Before you cite a line from it, treat the file as one person's capture on one date, check the date in the additions table, and if the claim matters, confirm it against the live product rather than the archive.

Frequently asked questions

Official sources

1. Official README
2. Project repository