claude-reviews-claude: a 17-chapter reading of Claude Code v2.1.88, written by Claude
Claude reads its own source code — 17-chapter architectural deep-dive into Claude Code v2.1.88. EN/ZH bilingual.
At a glance
- What is it?
- An MIT-licensed bilingual documentation project that walks through the internals of Claude Code v2.1.88 across 17 chapters. It is a reading companion, not a tool: the value is in the chapter structure and the numbers it cites, and the caveat is that none of it is independently verifiable from the repository alone.
- Who is it for?
- Adopt this if you are building an agent harness in TypeScript and want a structured map of how one production system separates its query loop, tool registry, permission pipeline and compaction layers. Skip it if you need reproducible measurements, a stable API reference, or anything that survives a version bump: the analysis is pinned to v2.1.88, and the repository carries no releases.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 167 days 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
What claude-reviews-claude actually is, and who it is written for
This repository is not a library, a CLI, or a plugin. It is a documentation site. The README describes it as a structured engineering analysis of Claude Code v2.1.88, covering architecture diagrams, code walkthroughs and design patterns, and states that the analysis was written by Claude after reading the TypeScript source. The subject is the harness around the model, not the model itself: the query loop, the tool registry, the permission checks, the compaction layers, and the multi-agent coordination code. The intended reader is someone who wants to understand how a production coding agent is assembled before building one, or who wants a map of a large TypeScript codebase they would otherwise have to read cold. The README claims the underlying codebase is 1,902 files and 477,439 lines of TypeScript, running on Bun with a React and Ink terminal UI. Those figures are the project's own, and I have not counted them. The bilingual split matters for reach: the README points to a Chinese edition and an English edition, with the GitHub Pages build supporting full-text search, dark mode and chapter navigation.
The 17 chapters, and what the numbering implies about the architecture
The chapter list is the most concrete thing in the repository, and it reads as a deliberate decomposition rather than a table of contents padded to look thorough. Chapter 1 covers the QueryEngine, described as 1,296 lines, and frames it as the brain that manages LLM queries, tool loops and session state. Chapter 2 covers the tool system and puts the count at 42 or more tools, each a self-contained module that registers, validates and executes. Chapter 3 covers a coordinator that spawns parallel workers and aggregates results. From there the chapters move outward: plugins at 18,000 lines, hooks at 8,000 lines with PreToolUse, PostToolUse and SessionStart named explicitly, a Bash engine at 11,500 lines, a permission pipeline at 9,500 lines described as defense in depth across config rules, tool checks and OS sandboxing. Chapters 8 through 13 cover agent swarms with mailbox IPC and permission delegation, session persistence with append-only JSONL and a parent-UUID chain, context assembly across three layers, a three-tier compaction system, startup and bootstrap, and a bridge system with a poll-dispatch loop. The last four chapters cover the UI layer with more than 140 components, the services and API layer including MCP server management and OAuth, infrastructure and configuration with a settings merge pipeline and GrowthBook feature flags, and telemetry with dual channels and a remote kill switch. The ordering is a real signal: the loop is chapter 1 because everything else is described as surrounding it.
The core claim: a dumb loop with a production harness around it
The README states the design philosophy directly: intelligence lives in the LLM, the scaffolding is just a loop. The diagram shows QueryEngine.query() calling the Claude API with streaming, then branching on stop_reason. If it is end_turn, output goes back to the user. If it is tool_use, the flow goes through a permission check, tool execution, and result injection back into the loop. Everything else in the 17 chapters is presented as a production-grade harness around that cycle: 42 or more tools, seven layers of defense, four compression layers, multi-agent coordination. Whether you find that framing persuasive depends on what you are building. If you are writing your own agent loop, the useful part is not the loop itself, which is short, but the chapters on compaction and context assembly, because those describe the failure modes that appear once a session runs long enough to exceed the context window. The README lists a three-tier compaction architecture: micro-compaction, session memory compaction, and LLM summary compaction, at 3,900 lines. That is a large amount of code for a problem most tutorials skip.
Reading it locally: the commands the README supports
The README recommends the hosted GitHub Pages build at openedclaude.github.io/claude-reviews-claude, and states that it supports full-text search, dark mode and chapter navigation, which it says is better than GitHub's native Markdown rendering. The Chinese entry point is at /zh-CN/ on that host. If you prefer to read the Markdown directly, the repository is on the main branch and the English edition is README_EN.md at the repository root, with the Chinese edition in README.md. The chapter files are linked from the README table as paths under chapters/, for example chapters/01-query-engine and chapters/02-tool-system, and the overview is a separate page at overview. The README also points to two community repositories for the underlying source: instructkr/claw-code, described as a restored version of the Claude Code source, and ChinaSiro/claude-code-sourcemap, described as the original TypeScript extracted from source maps. If you want to check any claim in a chapter, those two links are where the README expects you to go. There is no build step documented in the material I have, no package manifest shown, and no release artifact. Treat it as a static site and a set of Markdown files.
The verification problem, and why it is the main limitation
The README says the analysis is based on Claude Code v2.1.88 and that the source is available through community repositories, not from Anthropic. That means every line count, every file count, and every architectural claim in the 17 chapters rests on a third-party restoration of a codebase that Anthropic has not published. I cannot confirm from the supplied material that the restoration is complete, that it matches the version the chapters describe, or that the numbers in the README table are derived from the same snapshot. The line counts are also stated inconsistently: the README summary says 477,439 lines, while individual chapter entries give their own figures, and there is no stated method for how a chapter's line count was measured. This is not a reason to dismiss the project, but it changes how you should use it. Read the chapters for the shape of the design and the separation of concerns, and treat any specific figure as a lead to check rather than a fact to cite. A second limitation is version drift. The analysis is pinned to v2.1.88, the repository has no releases, and the last push recorded is 2026-04-01. If Claude Code has moved on, the chapters describe a snapshot, not a current system, and the README gives no process for tracking upstream changes.
How it differs from reading the source or using an API reference
The obvious alternative is to open the restored source in instructkr/claw-code and read it yourself. That gives you ground truth and no interpretation layer, at the cost of 1,902 files and a lot of time. The second alternative is Anthropic's own documentation, which describes how to use Claude Code rather than how it is built, and is authoritative about behaviour but silent about internals. This project sits between them: it is a guided reading of a specific version, organized by subsystem, with the chapter boundaries chosen to match architectural seams. The difference in approach is that it narrates rather than specifies. An API reference tells you what a function accepts and returns. A chapter here tells you why the permission pipeline has three stages instead of one, and what the trade-off was. If you want the former, this is the wrong artifact. If you want the latter and you are willing to verify the numbers, the chapter structure saves you the work of deciding where to start in a very large codebase.
Maintenance, licence and what the MIT grant does not cover
The repository is MIT licensed, which covers the text and any code in the repository itself. It does not cover the Claude Code source that the analysis describes, and the README is explicit that the source is obtained from community restorations rather than from Anthropic. That distinction matters if you plan to reuse anything: quoting the analysis is straightforward under MIT, but the underlying code is a separate question and I am not giving legal advice on it. On maintenance, the material shows no releases and no stated update cadence. The README frames the project as Season 1 with 17 episodes, which suggests a completed arc rather than an ongoing tracker. If you adopt this as a reference, the cost is not installation, since there is nothing to install, but the cost of re-verifying claims whenever you cite them, and the risk that a future Claude Code version invalidates the specifics while leaving the general architecture intact. The parts most likely to age well are the chapters on compaction, context assembly and session persistence, because those describe problems that any long-running agent hits regardless of implementation.
Editorial conclusion
Adopt this if you are building an agent harness in TypeScript and want a structured map of how one production system separates its query loop, tool registry, permission pipeline and compaction layers. Skip it if you need reproducible measurements, a stable API reference, or anything that survives a version bump: the analysis is pinned to v2.1.88, and the repository carries no releases. Before relying on any specific number in a chapter, open the corresponding source repository listed in the README and check the file count and line count yourself.
Community notes