claude-code-templates: a CLI catalog for Claude Code agents, hooks and skills

The blank .claude directory problem

Claude Code reads its behaviour from files in a project: agents, slash commands, hooks, settings and MCP server definitions. Getting a useful setup means writing several of those files by hand and knowing which format each one expects. claude-code-templates exists to skip that step. It is an npm package, also published under the short binary name cct, that pulls pre-written components from a central catalog at aitmpl.com and drops them into the right place.

The audience is developers who already use Claude Code and want a head start: a code-reviewer agent, a /generate-tests command, a PostgreSQL MCP entry, a pre-commit validation hook. The package.json description calls it a "Component templates and tracking system for Claude Code", and the tracking half matters, because the same binary also runs analytics, a conversation monitor and a health check. Those are separate features bolted onto the installer, not part of the catalog workflow.

How the catalog, the CLI and the components fit together

The repository layout separates concerns. cli-tool/ holds the Node.js CLI that ships to npm; cli-rust/ holds a Rust implementation; dashboard/ and cloudflare-workers/ serve the web interface and API; database/ holds schema for the tracking side. The published npm files list is narrow: cli-tool/bin/, cli-tool/src/, cli-tool/components/sandbox/, cli-tool/package.json and README.md. So the installed package contains the CLI and a sandbox component, and the broader catalog is fetched rather than bundled.

The .env.example confirms the fetch path with COMPONENTS_API_URL set to https://aitmpl.com/components.json. That file also lists SUPABASE_URL and SUPABASE_API_KEY for download statistics, a NEON_DATABASE_URL for changelog monitoring, and a SENTRY_DSN used by the dashboard API routes. None of those are needed to install a component; they belong to the hosted service behind the catalog.

Component selection happens on the command line. Each flag maps to a component type: --agent, --command, --mcp, --setting, --hook, --skill. The value is a path in the catalog, such as development-team/frontend-developer or git/pre-commit-validation. The --yes flag skips the interactive confirmation, which is what makes the tool usable in a script and also what makes it worth reading before you run it.

Installing and running a first install

There is no separate install step. The README's quick installation section uses npx against the published package, so Node and npm need to be present and nothing is added to your global path unless you choose to install it globally. Running the binary with no arguments opens an interactive browser instead of installing anything.

The first command below installs a single agent, a code reviewer, and confirms without prompting. The README gives this exact form. After it completes, the agent file should appear in your Claude Code configuration directory.

npx claude-code-templates@latest --agent development-tools/code-reviewer --yes

The README's fuller example combines several component types in one invocation: an agent, a command and an MCP integration. This is the pattern to copy when you are standing up a new project and want the whole set at once.

npx claude-code-templates@latest --agent development-team/frontend-developer --command testing/generate-tests --mcp development/github-integration --yes

Interactive browsing is the default when you pass no flags. From there you pick components from a menu rather than typing catalog paths, which is the safer route if you do not yet know the path naming scheme.

npx claude-code-templates@latest

Because the package declares both claude-code-templates and cct in its bin field, a global install gives you the shorter name. The README does not document an uninstall or rollback command, so if you want to reverse an install you are deleting the files it created by hand.

Analytics, chats and health check are a second product

Beyond the catalog, the CLI exposes four monitoring modes. --analytics reports on development sessions with live state detection and performance metrics. --chats serves a mobile-oriented view of Claude responses, with --chats --tunnel adding remote access through a Cloudflare Tunnel. --health-check runs diagnostics over your Claude Code installation. --plugins opens a dashboard for marketplaces, installed plugins and permissions.

These are genuinely different from installing a template, and the README treats them as such under an "Additional Tools" heading. The tunnel option deserves attention: exposing a conversation monitor beyond localhost is a deliberate trade of convenience for surface area, and the README does not describe an authentication layer for it. If you enable --tunnel, understand that the access control is whatever Cloudflare Tunnel provides, not something the project documents.

The analytics and statistics features lean on Supabase and Neon, per .env.example. That means the monitoring side is coupled to hosted infrastructure in a way the installer is not.

Where it gets in the way

The --yes flag is the sharpest edge. A hook component is not a text file you read later; hooks are automation triggers, and the README's own example is git/pre-commit-validation. Installing one writes configuration that causes commands to run during your git workflow. The catalog is community-contributed, and the README points contributors at the web interface to browse existing templates, which implies an open submission path. Treat every hook and MCP entry as code you are choosing to execute.

The project also straddles two languages. Python is listed as the primary language for the repository, while the shipped CLI is JavaScript (cli-tool/src/index.js) and a Rust implementation sits in cli-rust/. That is three toolchains in one repository, and the package.json test script is literally echo 'No tests specified'. There is no test suite to lean on if you want to verify a component before installing it.

Finally, the package is a thin client over a remote catalog. If aitmpl.com is unreachable or a component path changes, the install fails or fetches something different from what you expected. Pinning npx to a specific package version does not pin the catalog contents.

Compared with writing your own configuration

The obvious alternative is not another CLI; it is maintaining your own .claude directory in the repository and copying it between projects. The difference is one of control versus coverage. A hand-written setup contains only components you wrote, so you know exactly what each hook runs and each agent instructs. It costs you the time to learn the file formats and it does not benefit from anyone else's work.

claude-code-templates inverts that: you get a catalog of over a hundred components according to the README, at the cost of trusting upstream content and a remote fetch. The two are not mutually exclusive. A reasonable pattern is to use the CLI to bootstrap a new project, then commit the resulting files and stop running the installer, so the configuration becomes yours and stops tracking the catalog. The README does not describe that workflow explicitly, but nothing in the install model prevents it.

For teams already standardized on a shared internal configuration, the catalog adds a second source of truth. That is the case where it is the wrong tool.

Licence, maintenance and upgrade cost

The repository is MIT licensed, and the npm package declares the same. That is permissive: you can use, modify and redistribute the CLI and the component files, provided the licence notice travels with them. It says nothing about the components themselves, which are contributed content, and it says nothing about the hosted catalog service. If you plan to redistribute a bundled configuration, check the provenance of individual components rather than assuming the repository licence covers everything. This is not legal advice; read the LICENSE file and the component headers.

Maintenance looks current. The last push was on 2026-09-10, and the most recent release is v1.29.5 on 2026-09-09, described as adding the ability to install TypeScript hooks from the catalog. The release before that, v1.28.3, added plugin skills support to the skills manager, and v1.27.0 added a Docker sandbox provider. The gap between v1.27.0 in November 2025 and v1.28.3 in November 2025 is small, while v1.29.5 arrives roughly ten months later, so the cadence is uneven rather than steady.

Upgrade cost is low for the CLI itself, since npx always resolves the latest version unless you pin it. The real cost is re-checking components after a catalog change, because the installer does not record which version of a component you installed.

Editorial conclusion

Adopt claude-code-templates if you want a populated .claude directory quickly and you are comfortable letting a third-party catalog write agents, hooks and MCP entries into it. Skip it if you already maintain hand-written Claude Code configuration, or if you cannot review what --yes installs before it lands. Before committing, read the component files themselves rather than the catalog listing, and check what each hook executes, because hooks run commands on your machine. The repository was last pushed on 2026-09-10, so the catalog is current as of that date.

Frequently asked questions

Official sources

1. davila7/claude-code-templates on GitHub
2. License: MIT
3. Project website
4. README
5. Releases