claude-code-changelog: reading Anthropic's prompt drift release by release
Tracking prompts, feature flags and metadata of Claude Code releases. Subscribe to ↓
At a glance
- What is it?
- An unofficial archive that extracts Claude Code system prompts, feature flags and metadata at every release tag, so you can diff what changed between versions. It is a research artifact, not a tool you install.
- Who is it for?
- Adopt this as a reading habit if you need to know when Claude Code's prompts or flags shifted, and pin the two tags you care about in the compare view rather than browsing the tree. Skip it if you need reproducible measurements: the README itself says token totals are estimates and that file names can change across versions even when content lineage continues.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is that Claude Code ships constantly and its prompts are not in a changelog
Claude Code is distributed as an npm package, and its behaviour is shaped by system prompts and feature flags that ship inside the bundle. Anthropic's own documentation covers how to use the tool, not what textual instructions were sent to the model in build v2.1.44 versus v2.1.45. If you are debugging why an agent stopped asking for confirmation before a file write, or why a tool description reads differently this week, the answer lives in a diff nobody publishes.
This repository exists to publish that diff. It is explicitly labelled unofficial and community-maintained, and it tracks prompt and feature-flag evolution across releases. The audience is narrow: people doing prompt archaeology on a specific agent, researchers comparing instruction text across versions, and anyone building tooling that needs a stable reference for what Claude Code contained at a given tag. It is not for end users who just want the CLI to work.
What is actually inside the repository tree
The README lists the tracked artifacts by path. There are two legacy compatibility files, cc-prompt.md and cc-flags.md, kept per tag. The main payload sits in system-prompts/*.md, described as extracted prompt artifacts grouped by category, with indices under indices/. Derived metadata lives in meta/: flags.md, metadata.md, cli-surface.md and prompt-stats.md. Navigation is handled by annotated tags in the vX.Y.Z form plus GitHub releases.
The README's index block reports 11 total prompt files at the time of writing, with three generated index views: by tokens, by init (newest first), and by last edit (newest first). Those two lifecycle columns, Init and Last edit, are the mechanism for tracking a prompt artifact across renames. If a file disappears from one tag and a similarly sized file appears in another, the last-edit ordering is how you form a hypothesis that the content moved rather than died.
Recent releases follow the upstream version numbering directly: v2.1.267, v2.1.266, v2.1.265, all pushed within about two days of each other in early September 2026. That cadence is the point. A weekly snapshot would miss most of the interesting transitions.
Reading a change: the compare view is the whole workflow
There is no install step, no CLI, no configuration file. The README's own instructions are the workflow. Step one: pick two tags and open the compare view, with the example URL https://github.com/marckrenn/claude-code-changelog/compare/v2.1.44...v2.1.45#files_bucket. Step two: use system-prompts/ for per-file artifacts. Step three: use meta/ for structured summaries and aggregate metrics. Step four: treat the Init and Last edit columns as lifecycle hints. Step five, for deep full-history research, point a coding agent at the repository directly.
That last instruction comes with a caveat the author states plainly: GitHub Copilot on github.com is currently limited for broad historical search and analysis. So the recommended path for anything beyond a two-tag diff is to clone the repository and run an agent over the local checkout, not to query it through the web UI. That is a meaningful constraint on how the archive is consumed, and it is the kind of thing most project READMEs leave out.
The meta/ directory is where the aggregate view lives. flags.md and cli-surface.md give you the feature-flag and command-surface state without reading prompt text, which is faster when you only care whether a capability appeared. prompt-stats.md and metadata.md are the quantitative layer, and they carry the accuracy warnings described below.
The accuracy caveats are the most useful part of the README
The Data Quality and Interpretation Notes section is unusually candid, and it should govern how you use everything else. Token totals and per-file counts are estimates. Tokenization varies by model, tokenizer and runtime, so small differences between tags are expected and should not be read as content changes. Aggregate totals are described as useful directional signals, which is a polite way of saying do not put them in a table and call them measurements.
Estimated lines of code is derived from a prettified bundle line count and is described as only an approximation. Prompt files can contain near-duplicates or intentionally duplicated variants. 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. The README's closing instruction is the one to internalise: compare statistical deltas with raw diffs before drawing strong conclusions.
That list is not boilerplate. Each item describes a concrete way a naive diff will mislead you. The rename case is the worst, because it produces a large apparent deletion and a large apparent addition in the same commit range, which looks like a rewrite and may be a move.
Where this is the wrong tool
If you need to know what Claude Code does, this archive is the wrong source. It tells you what text shipped, not what the model does with it, and not whether a flag is active for your account, your region or your plan. A flag appearing in meta/flags.md means the flag exists in the extracted surface, not that it is enabled for you. Anyone treating the flag list as a feature list will draw the wrong conclusion.
If you need reproducible numbers, this is also the wrong tool. The README states the token counts are estimates and that the LOC figure is an approximation from a prettified bundle. There is no tokenizer pinned, no version stamp on the measurement method, and no error bar. For a paper or an internal capacity plan, those numbers are not usable as-is.
And if you need same-day notification, the repository is not the delivery channel. The automated pipeline feeds the @ClaudeCodeLog account on X, which the README describes as detecting new releases, extracting prompts and flags, generating structured diff summaries, and publishing threaded updates with focused diff links and screenshots. The repository is the backing store; the account is the alert. Reading tags by hand means you are polling.
The alternative: Piebald-AI/claude-code-system-prompts and cchistory
The README credits two other projects, and the difference in approach matters. Piebald-AI/claude-code-system-prompts is named as the inspiration for full prompt tracking. cchistory is named as the prompt extraction foundation, with a technical write-up linked at mariozechner.at. So the extraction method here is inherited rather than invented, and if you want to understand why a given artifact is shaped the way it is, the cchistory post is the primary source, not this repository.
The practical distinction is scope and packaging. A prompt-only tracker gives you the prompt text and asks you to bring your own diffing. This repository adds the derived layer (meta/flags.md, meta/cli-surface.md, meta/prompt-stats.md), the lifecycle columns, the generated indices, and an automated publishing pipeline on top. That is more surface area to maintain and more places for an estimate to drift, which is presumably why the accuracy notes are as long as they are. If you only want prompt text at a tag, the narrower project is the simpler dependency; if you want flags and command surface alongside it, the derived files here save you the extraction work.
Maintenance cost, licensing and what the repository does not say
The README's note block states that the archive takes time and money to run, naming server and token costs, and links to GitHub Sponsors and Buy Me a Coffee alongside the X follow. That is the honest maintenance picture: this is a continuously running extraction pipeline with an inference bill attached, sustained by one maintainer plus sponsors. There is no stated SLA. The status and uptime badges at the top of the README point at status.marckrenn.dev, which is where you would check whether the pipeline is currently healthy rather than assuming it is.
On licensing, the repository metadata supplied here does not include a licence identifier, and the README does not state one. The tracked content is Anthropic's prompt text extracted from a distributed package, which is a separate question from whatever licence covers the tooling. I cannot tell you what you may do with the extracted artifacts, and the absence of a stated licence in the material I have means you should check the repository's own licence file before republishing anything from system-prompts/ or meta/. That is a factual gap, not a legal opinion.
The upgrade path is unusual: there is nothing to upgrade. Tags are immutable history, and v2.1.267 does not replace v2.1.266. Your cost is the cost of re-reading diffs as new tags land, which at the observed cadence of roughly one release per day is a real recurring commitment if you intend to follow it closely.
Editorial conclusion
Adopt this as a reading habit if you need to know when Claude Code's prompts or flags shifted, and pin the two tags you care about in the compare view rather than browsing the tree. Skip it if you need reproducible measurements: the README itself says token totals are estimates and that file names can change across versions even when content lineage continues. Before relying on any delta, open the raw diff for the same pair of tags and confirm the change is real, not a rename or a near-duplicate variant.
Community notes