The tags are Claude Code's version numbers, not the archive's

Tags track the product, and one arrives per day

The recent tags are v2.1.286 on 30 September 2026, v2.1.287 on 1 October and v2.1.288 on 2 October, with the last push to the repository on 1 October. Those numbers are Claude Code's own version numbers, not the archive's, which is why the release history reads as a daily mirror of the upstream product. Annotated tags and GitHub releases exist for historical navigation, so the archive's releases are a by-product of tracking rather than a release programme of their own. The consequence for a reader is that a version you care about may simply be absent, since a tag only exists when the pipeline detected the release and had the budget to extract it, and the repository opens by admitting that running the archive costs money for a server and tokens. The pipeline itself is described in four steps: detect a new release, extract prompts and feature flags, generate a structured diff summary, and publish a threaded update with focused diff links and screenshots.

Eight top-level entries, no code and no licence

The whole repository is small. At the top level there are README.md, two legacy files, three directories and two dot entries: `.gitattributes` and `.github/`. The legacy pair is `cc-prompt.md` and `cc-flags.md`, kept per tag for compatibility. Then `system-prompts/`, holding extracted prompt artifacts grouped by category, `indices/` for the lookup tables, and `meta/` for derived data. The meta directory is four files: flags, metadata, a CLI surface summary and prompt statistics. There is no source directory, no manifest, no test suite and no build. The primary language is recorded as unknown, which is accurate for a repository of Markdown, and there is no LICENSE file in the tree, so nothing states the terms under which the archived prompts can be reused. Given that the material is proprietary system prompt text, that absence is the first thing to raise with the maintainer before building anything on top of it.

The compare view is the interface, and the indices are the map

The reading instructions are five steps and the first one is a URL pattern rather than a tool. Pick two tags and open the compare view, in the form `compare/v2.1.44...v2.1.45#files_bucket`, which buckets the diff by file. From there, `system-prompts/` holds the per-file prompt artifacts, `meta/` holds the structured summaries and aggregate metrics, and the Init and Last edit columns act as lifecycle hints for each artifact, telling you when a prompt first appeared and when it was last touched. The index block at the bottom of the README is generated between HTML comment markers, SYSTEM_PROMPTS_INDEX_START and SYSTEM_PROMPTS_INDEX_END, and reports 15 total prompt files with three orderings: by token, by init newest first, and by last edit newest first. The example version numbers in the compare URL, 2.1.44 and 2.1.45, sit a long way behind the current tags, so the instructions are written against a much earlier point in the history.

Every number in meta/ is an estimate, and the file says so

There is a data quality section, and it is the most useful part of the repository. Token totals and per-file counts are estimates. Tokenization can vary by model, tokenizer and runtime, so small differences are expected. Aggregate totals are described as useful directional signals, which is a careful way of saying not to quote them. Estimated lines of code come from a prettified bundle line count and are only an approximation. That last one has a second-order effect: a line count derived from prettified output measures the formatter as much as the code, so it should not be read as a proxy for how much logic a prompt contains. The section ends with the instruction that matters most, which is to compare statistical deltas with raw diffs before drawing strong conclusions. Read as a whole, the notes are an argument for using this repository as a diffing tool and treating its aggregates as a way to decide where to look, not as a dataset to cite.

File names are not stable identifiers across versions

The same section warns about the failure mode that makes prompt archives hard to query. File names can change across versions, through renames, splits and merges, even when the content lineage continues. A single conceptual prompt can appear under multiple files in some releases. Prompt files can contain near-duplicates or intentionally duplicated variants. Together those three statements mean a naive diff by path will report churn that is not churn, and a count of changed files is not a count of changed prompts. The Init and Last edit columns exist as a partial remedy, since they let you spot a lineage that continued under a new name, but they are hints rather than an identity map. This is also why the compare view, which shows the raw diff, is the recommended entry point instead of the aggregate numbers: a rename is obvious in a diff and invisible in a percentage.

The extraction method lives in someone else's repository

The credits section is short and it points away from this project. Full prompt tracking as an idea came from Piebald-AI's claude-code-system-prompts repository. The prompt extraction foundation is cchistory by badlogic, and there is a linked technical deep-dive explaining how cchistory works, published in August 2025. The remaining two credits are the official Claude Code documentation and the Claude Code package on npm, which are the sources the extraction reads from. That distribution of credit matters for anyone who wants to reproduce the archive: the detection and diffing here is the local work, while the part that actually pulls prompts out of a shipped client is somebody else's. Anyone extending this should start by reading the cchistory write-up, since the hard part of prompt extraction, deciding what counts as a prompt in a bundled JavaScript file, is solved or at least written up there rather than here.

The funding note is in the README, and the status badge is duplicated

The first block after the title is a note saying the archive takes some time and money, server and tokens, to run, and asking for support in three forms: a free follow on X, GitHub Sponsors, or a Buy Me a Coffee link. That is the honest framing of an operation whose cost scales with how many releases it tracks. Two details sit in that block as well. The status badge link appears twice in a row, the same status.marckrenn.dev address rendered twice, which is a copy-paste artefact in the first thing a visitor sees. And the account the archive exists to feed is linked from the repository description, which asks readers to subscribe, so the repository is the back end of an X account rather than a destination in its own right. Anyone deciding whether to depend on the archive should weigh that dependency: it is one person's infrastructure, funded by donations, fronting an upstream product that changes daily.

It tells you not to use Copilot for the deep search

The fifth reading instruction is a warning about tooling. For deep full-history research, the instruction is to point a coding agent at the repository directly, and the reason given is that GitHub Copilot on github.com is currently limited for broad historical search and analysis. That is a narrow, practical claim about a hosted tool's ability to search a large history, and it is the kind of statement worth verifying for yourself rather than taking on trust, since assistant capabilities change. What it does establish is the intended usage pattern: this is a corpus to be queried by an agent that can walk thousands of files, not a page to be read. Combined with the rest of the guidance, the workflow is pick two tags, diff them, then send an agent at the interesting files, and ignore the token columns unless you are deciding where to start. The system prompts index, with 15 files ordered three ways, is a reasonable place to begin.

Editorial conclusion

Judgment: this is an archive first and a tool second, and it is more useful for the two-tag diff than for any number it publishes. The compare view plus the raw prompt files is the part that holds up, because a renamed file or a split variant is visible in the diff while it is invisible in a token total. Treat everything under meta/ as a hint rather than a measurement: the repository says so itself, in unusually direct language, and the most useful line in it is the instruction to check statistical deltas against raw diffs before concluding anything. Two practical cautions. There is no LICENSE file in the tree and the language is recorded as unknown, so nothing here is clearly licensed for reuse, and since the tags mirror upstream version numbers, a version you need may never have been captured if the archive was down when that release shipped. For anyone doing systematic prompt research, read the extraction foundation it credits first, because that is where the method actually lives.

Frequently asked questions

Official sources

1. Issues
2. marckrenn/claude-code-changelog on GitHub
3. Project website
4. README
5. Releases