cc-use-exp: a layered config template set for six AI coding CLIs, now frozen at v1.0.40

The repeat problem cc-use-exp is built around

Every AI coding CLI keeps its own config location and its own file format. Claude Code reads from ~/.claude/, Gemini CLI from ~/.gemini/, Codex from ~/.codex/ with AGENTS.md plus rules, instructions, skills and per-profile TOML files, Cursor from ~/.cursor/rules/*.mdc and ~/.cursor/skills/, and GitHub Copilot from ~/.github/copilot-instructions.md and ~/.github/instructions/. If you use more than one of them, the same project conventions get retyped into each location, and they drift apart within a week.

The README frames the target user directly: people who already use one or more of Claude Code, Antigravity CLI, Gemini CLI, Codex, Cursor and GitHub Copilot, who do not want to restate their stack, project structure and coding conventions in every session, and who want team conventions to live as maintainable rules, skills and workflow files. The stated goal is not longer prompts. It is splitting the conventions that keep recurring into separate structures: global principles, approval rules, language skills and task workflows, each with its own job.

One worked example in the README is API contract drift between frontend and backend: a list endpoint returns an array while the frontend reads it as a paginated object, a filter endpoint returns an empty array while matching records exist, and the detail or status-option endpoints use yet another shape. The project's answer is three layers: a global principle that says check the contract before adding frontend tolerance, a skill named cc-api-contract-safety that checks success-response wrapping, pagination shape, filter-option sources and the exit condition for temporary compatibility code, and a task template that records when the contract was confirmed and when the compatibility shim should be removed. That is a concrete governance model, not a prompt library, and it is the clearest signal of what the author means by a config system.

What the sync scripts actually write, and where

The mechanism is a mapping table, not a runtime. The repository holds per-tool directories at its root, and sync-config.sh (or sync-config.bat on Windows) copies each one into the matching user-level location. From the README, the mapping is: .claude/ to ~/.claude/, .antigravity/ to ~/.gemini/config/ for Antigravity CLI, .gemini/ to ~/.gemini/ for the older Gemini CLI, .codex/global/AGENTS.md to ~/.codex/AGENTS.md, .codex/global/rules/ to ~/.codex/rules/, .codex/instructions/*.md to ~/.codex/instructions/, .codex/skills/ to ~/.agents/skills/, .codex/profiles/*.toml to ~/.codex/{profile}.config.toml, .cursor/rules/*.mdc to ~/.cursor/rules/ (described as a compatibility sync, since in-project .cursor/rules/ remains the primary path), .cursor/skills/* to ~/.cursor/skills/, .cursor/commands/*.md to ~/.cursor/skills/{name}/SKILL.md as a command-to-skill compatibility layer, .cursor/templates/* to ~/.cursor/templates/, .github/copilot-instructions.md to ~/.github/copilot-instructions.md, .github/instructions/*.instructions.md to ~/.github/instructions/, and a local AGENTS.md to ~/.github/AGENTS.md.

The layering claim is that rules stay resident while skills load on demand and workflows are invoked explicitly. That is a statement about how the files are meant to be consumed by each tool, and it is worth checking against your tool's own loading behaviour before assuming it holds. The README does not quantify the context saving, and I cannot verify it.

Codex gets different treatment from the rest. The README describes incremental deployment: the script does not overwrite ~/.codex/ wholesale, does not touch auth.json, history.jsonl, logs, sqlite or cache files, and merges AGENTS.md through a managed block. It manages only the profile files, rules, instructions and skills that this project owns. It also states the script will not change your existing default model, provider or base_url. For Claude Code and Gemini CLI the README says historical conversations, personal config and credentials such as oauth_creds.json are preserved. Those are claims about the script's behaviour, and the only way to check them is to read the script.

Install commands, per tool

Claude Code has two paths. The plugin route runs inside a session: /plugin marketplace add doccker/cc-use-exp followed by /plugin install cc-use-exp@cc-use-exp, and later /plugin update cc-use-exp@cc-use-exp. The README notes this installs skills and commands only. The fuller path requires the plugin first, then /skill-install, which additionally syncs rules and templates and supports cross-tool use for Gemini, Codex and Cursor; updates go through /skill-update. The README's comparison table is explicit that the plugin route is Claude Code only.

Codex CLI offers an in-session installer, $skill-installer install https://github.com/doccker/cc-use-exp/.codex/skills/cc-skill-installer, updated by rerunning the same command, or a shell route that needs no Codex session: bash <(curl -sL https://raw.githubusercontent.com/doccker/cc-use-exp/main/tools/install-codex.sh). Antigravity CLI and Gemini CLI share one script, bash <(curl -sL https://raw.githubusercontent.com/doccker/cc-use-exp/main/tools/install-gemini.sh), which the README says detects both the newer Antigravity config path (~/.gemini/config) and the older Gemini CLI path (~/.gemini). Cursor and Copilot each have their own script, install-cursor.sh and install-copilot.sh, both run the same way and both updated by rerunning.

The manual route is a clone plus a script: git clone https://github.com/doccker/cc-use-exp.git, cd cc-use-exp, ./tools/sync-config.sh, or tools\sync-config.bat on Windows. Note that piped curl scripts and a local clone are not equivalent in reviewability. If you are deciding whether to trust this on a work machine, the clone route lets you diff the script before it writes anything into your home directory.

The maintenance boundary is the main risk

The repository carries a banner stating it is no longer maintained, in both Chinese and English. The stated reason is repeated licence violations. Existing content stays available, but the README says all new capabilities have moved to dev-agent-kit/recipes, and that new content is updated only there. The listed additions in the new project are full support for a seventh platform (the pi editor) with enhanced config, dangerous-command interception and a quota status bar, a unified CLI status bar showing model and quota across tools, new skills synced across seven platforms, and automated native-binary detection and patch dispatch.

Access to the new project is a one-time ¥699 (roughly $99) paid membership with lifetime updates and a private group, reached through WeChat or doccker@pm.me. That is a legitimate funding model, but it changes the calculus: this repository is a snapshot, and every platform it targets is moving. If Claude Code, Codex or Cursor changes a config path or a skill format, nothing here will be patched. The last release listed is v1.0.40 from 2026-06-30, with v1.0.39 and v1.0.38 before it, so the cadence was real while it lasted.

The second limitation is the licence. The README badge shows PolyForm NC, and the repository metadata reports NOASSERTION, meaning the licence could not be classified automatically. PolyForm Noncommercial restricts commercial use, so a company deploying these rules and skills into employee machines has a question to answer before running any script. I am not giving legal advice; read LICENSE and your own policy. The README's stated reason for going closed, repeated licence violations, suggests the author is sensitive about exactly this. The third limitation is scope: this is configuration, not enforcement. Nothing in the material suggests the sync scripts validate your repository, and the defensive rules described (avoiding test-adaptation errors, dangerous commands, over-refactoring) are instructions to a model, not a sandbox.

Where a plain AGENTS.md or a project-local rules file wins

The obvious alternative is what most teams already do: one AGENTS.md at the repository root, plus a .cursor/rules/ directory checked into the project. The README itself concedes that in-project .cursor/rules/ remains the primary path and the user-level sync is a compatibility measure. The difference in approach is real. A project-local file travels with the code, so a new contributor gets the conventions by cloning, and a change to the conventions shows up in a pull request with a reviewer. cc-use-exp writes into user-level directories, so conventions live on the machine, not in the repository, and a change to them is invisible to code review.

That trade favours cc-use-exp in one specific case: conventions that are genuinely cross-project, such as how you want a model to behave before running a destructive command, or a general rule about checking API contracts before adding tolerance code. Those do not belong to any one repository, and copying them into every repo is the repetition this project exists to remove. The trade favours project-local files for anything that depends on the codebase, which is most things.

A second alternative is per-tool configuration written by hand. That is what cc-use-exp replaces, and the honest comparison is maintenance cost. Six tools times a rules file each, times every convention change, is the arithmetic the project is betting against. If you use one tool, the arithmetic does not favour it, and the README's own feature table says the plugin route covers Claude Code only, which hints the author expects multi-tool users.

What to verify before running the sync script

Read tools/sync-config.sh first, because the README's preservation claims are the whole basis for trusting it. The specific things to confirm: that the Claude Code branch does not delete existing files under ~/.claude/, that the Gemini branch leaves oauth_creds.json alone, and that the Codex managed-block merge in ~/.codex/AGENTS.md delimits its block with markers you can find and remove later. If you cannot find those guarantees in the script, run it on a machine you can restore.

Check whether your installed tools still use the paths in the mapping table. The README already shows the Antigravity and Gemini split, which is evidence that these paths move. If your Cursor version no longer reads ~/.cursor/rules/, the compatibility sync writes files nothing consumes, and you will not get an error.

Decide where the files should live. The manual route (git clone, then ./tools/sync-config.sh) keeps the source tree on disk, so you can diff a future version against your own edits. The curl-piped installers do not, and because the repository is frozen, there is no future version to diff against anyway. That argues for the clone.

Finally, settle the licence question before deployment rather than after. PolyForm NC plus a paid successor project is a coherent position, but it means the free tree is a one-time acquisition, not a dependency you can expect anyone to fix.

Editorial conclusion

Adopt cc-use-exp if you run two or more of the six supported CLIs and want a single rules and skills tree that deploys into each tool's user directory, and if the PolyForm Noncommercial terms fit how you work. Do not adopt it if you need upstream fixes, because the maintainer states new development happens only in dev-agent-kit/recipes. Before deploying, read tools/sync-config.sh end to end and confirm it will not overwrite your existing ~/.claude/ and ~/.gemini/ files, then run it once on a machine whose config you can restore.

Official sources

1. doccker/cc-use-exp on GitHub
2. Issues
3. Project website
4. README
5. Releases