Claude Code Tresor: 141 agents, 19 slash commands and an orchestration layer for Claude Code

The gap Claude Code Tresor is trying to fill

Claude Code ships with a small set of built-in behaviours. What it does not ship with is a library of opinionated agents for specific jobs, so most users end up writing the same security reviewer or test generator prompt by hand, in every project, with inconsistent results. Tresor is an attempt to ship that library as files: agents, skills, slash commands and prompts, organized so they can be dropped into a Claude Code configuration and invoked by name.

The target user is someone who already uses Claude Code and is willing to maintain a directory of agent definitions alongside their code. It is not aimed at people who want a hosted service. Everything is plain files in the repository, under agents/, subagents/, commands/, skills/ and prompts/, which means the value you get depends on how much of that structure you actually wire up. The README describes the collection as covering "the entire development lifecycle", which is a broad claim; what is verifiable is the inventory it lists: 141 agents, 19 slash commands and 10 orchestration commands added in v2.7.0.

How the agent and command layers fit together

The repository separates three things that are easy to conflate. Slash commands are the entry points a user types, such as /scaffold, /review or /audit. Agents are the workers those commands dispatch to. Skills and prompts are reusable content the agents draw on.

v2.5.0 reorganized agents into a subagents/ directory with 10 color-coded team categories, alongside 8 core agents, for 141 total. v2.7.0 then added an orchestration layer on top: the README states the orchestration commands use intelligent agent selection that auto-selects from the 141 agents based on tech stack, run in 3 to 4 phases with parallel and sequential execution, and perform dependency verification so that parallel agents do not step on each other. That last point is the design detail worth noticing. Parallel agent execution is only safe if the agents do not write to the same files or depend on each other's output, and the repository treats dependency checking as a first-class step rather than an assumption.

The commands are grouped by domain. Security covers /audit, /vulnerability-scan and /compliance-check. Performance covers /profile and /benchmark. Operations covers /deploy-validate, /health-check and /incident-response. Quality covers /code-health and /debt-analysis. The README lists estimated durations for the security commands, from 30 to 60 minutes for /vulnerability-scan up to 2 to 4 hours for /audit; those are the project's own estimates, not measured results.

Installing Claude Code Tresor and running a first command

The README points to GETTING-STARTED.md for setup and mentions a one-command installation with automated updates, but it does not print the install command in the portion available here. Treat GETTING-STARTED.md as the source of truth rather than copying a command from a blog post. If you prefer not to install locally, the README links a Smithery listing at smithery.ai/skills?ns=alirezarezvani, which is the hosted route.

Once the files are in place, the first useful check is whether the command layer is visible. The README's own examples show the invocation syntax, so start with the least destructive command in the list, /review against staged changes:

/review --scope staged --checks security,performance

What you should see is a review output scoped to files you have staged, with the checks limited to security and performance. If nothing happens, the command files are not in the location your Claude Code installation reads, which is the most common failure at this stage.

For a project-scaffolding task, the README gives this form:

/scaffold react-component UserProfile --hooks --tests

That should produce a component directory with hooks and test files. The flags shown are the ones the README uses; do not assume additional flags exist.

The orchestration commands are heavier. A dependency scan is a reasonable second step because it is bounded and produces artifacts you can inspect:

/vulnerability-scan

The README describes this as CVE and dependency scanning with NVD correlation, SAST, exploit detection and auto-fix, estimated at 30 to 60 minutes. If you are not prepared for an auto-fix pass over your dependency files, run it on a branch.

Where the design gets in your way

The most concrete limitation is in the project's own release history. v2.5.0 renamed three core agents: @architect became @systems-architect, @code-reviewer became @config-safety-reviewer, and @debugger became @root-cause-analyzer. The README labels these as breaking changes and the repository ships a MIGRATION-GUIDE.md and a MIGRATION.md to handle them. Any collection that renames its own entry points is going to cost you a migration pass, and the presence of two migration documents suggests the process has already been revised at least once.

The second issue is scale as a usability problem. 141 agents is not obviously better than 20 good ones. The README's answer is auto-selection based on tech stack, which moves the problem rather than removing it: when the selector picks the wrong agent, you need to understand the category structure well enough to override it. The subagents/ tree is organized into 10 team categories, so that structure is the thing to learn.

The third is that estimated durations of 2 to 4 hours for /audit are a real cost. These are not quick linting passes. If your workflow cannot tolerate a long-running agent session that may need review afterwards, the orchestration commands are the wrong part of this repository to adopt, and you should stay with the smaller development commands.

Tresor versus writing your own Claude Code subagents

The obvious alternative is not another repository, it is your own subagents/ directory. Claude Code supports custom agents, and a hand-written agent for your codebase will encode your conventions, your test framework and your deployment target, none of which a general-purpose collection can know in advance.

The difference in approach is breadth versus fit. Tresor gives you 141 pre-written agents covering security, performance, operations and quality, with a documented category structure and a set of orchestration commands that chain them. A hand-written set gives you perhaps five agents that match your stack exactly and that you can debug because you wrote them. The trade-off is real in both directions: Tresor gets you to a working security audit today, while a custom agent set is cheaper to maintain over a year and will not rename itself in a minor release.

A middle path is visible in the repository's own structure. The agents are plain files, so you can copy the ones you want into your own configuration and ignore the rest. That avoids the orchestration layer entirely and sidesteps the auto-selection question, at the cost of not getting the multi-phase execution the v2.7.0 release notes describe.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive position and it matters here because you are expected to copy agent files into your own setup. This is not legal advice; if you are redistributing modified agents inside a product, have your own counsel read the LICENSE file.

The last push to the repository was on 2026-07-03. The most recent release listed is v2.6.0 from 2025-11-16, while the README's own header describes v2.7.0 as the current version and the repository root contains RELEASE-NOTES-v2.7.0.md. That mismatch between the release list and the README is worth knowing before you assume a tagged version corresponds to what you read in the docs.

Upgrade cost is the part to budget for. Two of the three releases described in the README carry structural changes: v2.5.0 reorganized the agent directory and renamed core agents, and v2.7.0 added 10 orchestration commands totaling what the README states is 12,682 lines of code. v2.6.0 is described as backward compatible with no breaking changes, so the pattern is not every release, but it is often enough that pinning to a version and reading CHANGELOG.md before pulling is the cheaper habit.

Editorial conclusion

Adopt it if you already run Claude Code daily and want pre-written agents for security, performance and operations work rather than writing your own prompts from scratch. Skip it if you want a single small tool, or if you cannot accept that the repository's own upgrade path has already renamed agents once, in v2.5.0, which broke @architect, @code-reviewer and @debugger. Before installing, read MIGRATION-GUIDE.md and RELEASE-NOTES-v2.7.0.md in the repository root, then check GETTING-STARTED.md for the install path that matches your setup, because the README points at more than one.

Frequently asked questions

Official sources

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