cfrs2005/claude-init: an archived configuration template that tells you not to install it

The first thing the README says is that you should not use it

Most archived projects archive quietly. This one announces itself, in a banner near the top, as being kept for study and reference only, and the status block underneath is explicit on three points that are unusual to see stated this plainly.

It gives a project date of July 2025 and a positioning line clarifying that this is a project initialisation tool and explicitly not a localised version of Claude Code. It then states the current status, which is that the client iterates quickly and this project is kept only as a learning reference. And in the background section it repeats the disclaimers as a list: this is not a Chinese version of the client, it is not an official alternative, its configuration may already be out of date, and the recommendation is to use the official version and consult the official Chinese documentation.

That is a strange thing to find in a repository whose short description, still visible in the metadata, sells a one-click install of a complete localised experience with a zero barrier to entry, integrated MCP servers, smart context management, security scanning, and support for access without a network proxy. The description and the README describe different products, and the README is the newer of the two. That mismatch is the first thing a reader should resolve, and the resolution is easy: the repository is a collection of configuration examples, the marketing line is stale, and the author has said so in the document everyone reads first.

The dates support that reading. The last tagged release is v1.3.0 from January 2026, the previous two are from October and September 2025, and the last commit to the default branch is dated 2026-03-12. A project that decided in early 2026 that it was a learning reference would keep the code around, keep the tags, and stop adding features, which is what those dates look like.

The v1.3.0 release is a localised copy of someone else's configuration

The headline feature of the current release is worth reading carefully, because it tells you where most of the content came from.

The release integrates a Chinese-localised version of a configuration collection called Everything Claude Code, attributed to a handle whose team the README says won an Anthropic and Forum Ventures hackathon with it while building real products over ten months of iteration. The README names two individuals as the winners and links both the upstream project and a post describing the configuration.

So the largest part of this repository's current value is a translation job applied to someone else's work, with attribution given. That is worth stating plainly for two reasons. It means the ideas in the agent, command and rule files are not original to this repository, and a reader evaluating whether the approach is any good should read the upstream project, which will be in English, more recent, and not filtered through a project that now describes itself as a reference. And it means this repository's own contributions are the localisation, the directory layout, the shell scripts and the documentation, which is a smaller thing than the release headline suggests.

The attribution is explicit and links out, which is the right thing to do and is the main reason this reads as a legitimate fork rather than a passing-off. It is also the reason to be careful about the version numbers. This project is at 1.3.0 and the configuration it carries belongs to a different project with its own release cadence, so the two version numbers carry no relationship to each other and a changelog entry in one tells you nothing about the other.

One more detail belongs in this section rather than later. The documentation carries a repeated caveat above the feature sections, in effect saying that these configurations are for reference and may need adjusting for the latest version of the client. That caveat is attached to the integrations specifically, which suggests the author knew where the rot would start.

Nine agents, and the division of labour they encode

The configuration set is organised into six kinds of file, and the counts are given, which is the kind of detail most template repositories omit.

There are nine agents, seven or more skills, ten commands, eight rule files, several hooks and three working contexts. The directory layout under the templates folder is:

templates/.claude/
├── agents/           # 9 个专用子智能体
├── skills/           # 工作流定义与领域知识
├── commands/         # 10 个快捷斜杠指令
├── rules/            # 8 个强制性规则
├── hooks/            # 自动化钩子脚本
├── contexts/         # 3 种工作上下文模式
├── mcp-configs/      # MCP 服务器配置示例
├── plugins/          # 插件生态系统文档
└── examples/         # 配置示例和会话记录

The nine agents are the interesting part, because their names describe a team rather than a toolset. There is one for planning a feature into executable steps, one for evaluating architecture options, one that guides a test-driven cycle through its red, green and refactor phases, one for reviewing code quality and security across several dimensions, one for vulnerability analysis, one for diagnosing build failures, one that runs end-to-end browser tests, one for removing dead code, and one for keeping documentation in step with the code. The boundaries between them are the point. Build errors and dead code are separated from general refactoring precisely so that a routine cleanup does not become a sweeping rewrite, and the dedicated review agent is separate from the security agent so that a style complaint and a real finding do not arrive in the same voice.

The commands are the user-facing half, and they are named as verbs you would type: a test-driven workflow, a planning workflow, generating end-to-end tests, a code review, a build fix, a dead code removal, a coverage analysis, a code map refresh, a documentation sync, and a learning command. The correspondence between commands and agents is the mechanism by which a single slash invocation produces a delegation, which is what makes the arrangement more than a folder of prompts.

The rule files are the part with teeth. There is one forbidding hardcoded secrets and mandating security checks, one on immutability and file organisation, one stating test-driven principles with an eighty percent coverage requirement, one on commit format and pull request process, one on when to delegate to a subagent, one on model selection and context management, one on API response shapes and design patterns, and one documenting the hook system. Written as rules rather than suggestions, these are the files most worth taking, because they survive a client update better than a prompt that depends on a particular tool signature.

The context window warning is the most useful page in the repository

Buried between the rule descriptions and the directory listing is a short block about context window management, and it is the single most actionable piece of advice in the whole project.

The warning is specific and quantitative. Enabling too many tools at once is said to be capable of shrinking a two hundred thousand token context window down to seventy thousand. Not gradually, and not by the size of the tool definitions alone in a way you could predict, but to roughly a third of its size. That is the kind of number an engineer needs, because a context window shrinking by two thirds does not fail loudly, it produces an assistant that seems to have forgotten the earlier half of the conversation.

The heuristics that follow are four, and they form a coherent policy rather than a list of tips. Configure twenty to thirty MCP servers in total. Keep fewer than ten enabled for any given project. Keep the number of active tools under eighty. And use the mechanism for disabling servers you are not currently using, rather than deleting them, which is the difference between a global registry and a per-project set.

The numbers are worth taking apart, because they encode a distinction that is easy to miss. Twenty to thirty configured is a library, and a library costs nothing until it is enabled. Fewer than ten enabled per project is a budget, and the budget is per project precisely because what a project needs changes. Eighty active tools is a ceiling on what the model can choose from at once, which is a different constraint from the byte cost of the definitions: past some point, too many available tools is a reasoning problem rather than a context problem, because the model spends turns choosing instead of doing. Anyone who has watched a session stall while the assistant deliberates between forty near-identical tools will recognise the failure this number is preventing.

That distinction is also the reason the advice is not more prescriptive. There is no recommendation about which servers to enable, because the right answer depends on your project, and there is no threshold at which quality degrades, because nobody has measured one. The block is a set of bounds derived from experience, offered as such. It is a better artefact than a benchmark would have been at this stage, and it is the part of this repository worth quoting.

Two shell scripts at the root, and a recommended path that avoids them

The repository root contains an install script and a setup script, which is what you would expect from a project whose short description promises one-click installation. The README, however, recommends something else entirely, and the difference is worth tracing.

The recommended path is to install the official client from the official documentation, and then to treat this repository as a reference. The commands given for that are a clone and a directory listing:

git clone https://github.com/cfrs2005/claude-init.git
cd claude-init

ls templates/.claude/

Look at what that does. It clones the repository and prints a directory name. It does not run the install script, it does not modify your home configuration directory, and it does not write anything outside the clone. The second documented workflow is the same idea taken one step further: read a specific file, then copy that one file into your own configuration directory if you want it.

That is a well judged default for a project whose own status note says its configuration may be stale. A script that writes into a dot directory in your home folder, on the strength of a template written for a client version from mid-2025, is a bad thing to run by default. The existence of such scripts is normal for this kind of project, and their presence next to a recommended workflow that does not use them is a reasonable position, but it does mean the risk sits in a file most readers will open without reading.

The rest of the root is unremarkable and mostly informative. There is a changelog, a contributing guide the readme badges point at, a documentation directory, and an examples directory holding three worked projects, one each for Python, for Node and for a web application. Three example projects is more than most template repositories ship, and they are the best way to judge whether the rules and agents actually produce anything usable, since the rules are the kind of thing that either fits your project or fights it.

One small entry deserves a mention because it explains something. There is a file whose name marks the repository as excluded from a specific editor's indexing. Whatever its history, it is a signal that the author has been running an AI editor over this codebase, which is a reasonable thing to do when the project is about AI editor configuration.

What the integrations and hooks add, and the caveat attached to all of them

The feature list describes a three layer documentation approach with a base layer, a component layer and a feature layer, automatic context injection so a subagent picks up project context on its own, document routing that loads a level of detail according to how complex the task is, and cross session state so a task can be handed from one session to the next. That last one is the most ambitious claim, since it is the difference between a template and a continuity system.

The integration layer is described as a hook system with scripts, MCP server configuration for things like a second model for consultation and a documentation lookup service, a security scan that checks for sensitive information before an MCP call is made, and a notification system. The security scan deserves a second look, because a check that runs before a tool call is a genuinely different design from a check that runs after, and it is the kind of thing that costs nothing to include and prevents one class of accident.

The notification feature is more concrete than the rest: custom sounds for events, with the files living in a hooks subdirectory in a user's configuration folder and three audio formats supported. That is the sort of small, specific, immediately noticeable thing that distinguishes a configuration somebody actually uses from one assembled from a template.

Every one of these sections carries the same caveat in the documentation, stating that the configuration is for reference only and may need adjusting for the latest version of the client. On the integrations specifically, the trigger is described conversationally, asking the client in natural language to consult a second model for architecture questions or to look up documentation for an unfamiliar library. Those phrasings are tied to how the client interprets requests, which is the most likely thing to have drifted since the templates were written.

Which is the honest summary of this repository. The rule files and the context window heuristics will still be useful in a year because they encode judgement. The command names, the trigger phrasings and the agent prompts depend on a specific client generation and will need editing, which is exactly what the author says and exactly why the project no longer recommends running its own installer.

Editorial conclusion

Treat cfrs2005/claude-init as a folder of example configuration to read and copy selectively, not as a product to install, because the project's own status note says it may be out of date relative to the official client and that it is a learning reference. The specific things worth taking are the context window heuristics about how many tools to keep enabled and the rule files, which are written as enforceable constraints rather than advice. Do not run the shell scripts at the repository root on a machine you care about without reading them first, and do not rely on the repository description to tell you what the project does, since it advertises capabilities the README explicitly disclaims. If you want the upstream configuration this project localises, go to that project directly, and if you want the client, use the official one, which is what the README asks.

Frequently asked questions

Official sources

1. cfrs2005/claude-init on GitHub
2. Issues
3. License: MIT
4. README
5. Releases