vibecosystem: a Claude Code agent pack that ships its own learning loop
AI software team for Claude Code - 138 agents, 295 skills, 73 hooks. Self-learning, multi-agent swarm, autonomous skill evolution.
At a glance
- What is it?
- vibecosystem layers 138 agents, 296 skills and 74 hooks on top of Claude Code, with profiles that cut the loaded set down to 12 agents and 32 skills. The interesting part is the learning loop and the installer's ownership manifests; the weak part is that almost none of the claims come with evidence you can check before installing.
- Who is it for?
- Adopt vibecosystem if you already work inside Claude Code and want a pre-built role set without writing agent files yourself; start with ./install.sh --profile core and run vibeco effective-config before adding anything else. Do not adopt it if you need per-component provenance, or if you cannot accept a learning loop that writes rules from observed errors.
- 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 38 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
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
The single-assistant problem vibecosystem is aimed at
The README states the problem plainly: Claude Code is one assistant, so the planner, reviewer, security auditor and tester roles all fall back on you. vibecosystem's answer is to pre-write those roles as agent files and let Claude Code pick them up. The intended user is someone who already runs Claude Code daily and has hit the ceiling of prompting one model in one window. It is not aimed at people who want a standalone agent framework with its own runtime; the repository's primary language is C#, but the components described in the README are agent definitions, TypeScript hooks and shell installers, so the C# figure likely reflects tooling rather than the thing you install. The README claims that after setup you say "build a feature" and 20+ agents coordinate across 5 phases. That is an assertion about behaviour, not a measurement, and the README does not show the transcript.
Agents, skills and hooks as three separate load-bearing layers
The architecture is three layers that can be enabled independently. Agents are role definitions. Skills are reusable knowledge units, described as spanning TDD workflows to Kubernetes patterns. Hooks are TypeScript sensors that "observe, filter, and inject context", which is the only mechanism in the README that changes what the model sees rather than what it is told to do. Rules are a fourth, smaller layer: 20 behavioural guidelines that shape output.
The v3.4 release notes describe a change that matters more than the counts. The lean core runtime is now the default, and context injectors have bounded event and session budgets. An injector without a budget is a slow context leak, so bounding it is the right call. The same notes say installer ownership manifests make backups and pruning explicit, which means the installer records which paths it created. That is what makes uninstalling tractable, and it is the detail most ecosystem packs skip.
The self-learning loop and what it actually writes
Two releases describe the learning machinery. v2.2 added Agent Memory, described as persistent per-agent memory, plus Dream Consolidation for cross-session memory cleanup and Smart Recall, which scores memory using frontmatter. v3.2.0 is titled Autonomous Skill Evolution Loop. The README's summary is blunter: every error becomes a rule, automatically.
That sentence is the whole design and also the whole risk. A loop that converts errors into rules will accumulate rules that encode one bad session. The README does not describe a review step, a confidence threshold, or a way to expire a rule that stopped being true. Dream Consolidation is described as memory cleanup, not rule pruning. If you enable the memory profile, you are opting into a system that edits its own behavioural guidance, and the material gives no rollback story beyond the installer manifest. I would treat the memory profile as the one to enable last, after you have watched what the core profile writes.
Profiles are the real cost control
The default core profile loads 12 agents and 32 skills. The full profile loads 138 and 296. That is roughly an order of magnitude difference in what gets pulled into context, and it is the single most consequential configuration choice in the project. The README lists eleven profiles, from minimal (an alias for core) through frontend, backend, fullstack and devops, up to full, which it labels as all legacy.
The quality, context, memory and orchestration profiles are all 12 to 14 agents and 32 to 36 skills, so they are core plus one capability each. Switching is a single command, vibeco profile frontend, and the README frames it as a token-saving move. Note that the profile table gives approximate counts with tilde prefixes for the domain profiles, so the numbers are not exact. The v3.0 notes mention Claude-adapter model routing across Haiku, Sonnet and Opus tiers, and v3.4 says Codex uses a single model authority, luna_worker with gpt-5.6-luna at max reasoning, with Claude-only Opus and Sonnet frontmatter isolated to the Claude adapter. That isolation is a sensible boundary: it stops model-specific settings from leaking across CLIs.
Installing it: three paths and the commands that follow
The README gives three install routes. The npm path is npx vibecosystem init. The one-liner pipes install-remote.sh from the main branch into bash. The manual path clones the repository, changes into it and runs ./install.sh --profile core.
After install, the vibeco command is available, and this is where you should spend your first ten minutes. vibeco effective-config prints the model, worker, profile and budgets, which is the only documented way to confirm what the profile actually resolved to. vibeco doctor runs a health check, and given that there are 74 hooks, hook health is the failure mode most likely to bite silently. vibeco stats and vibeco list agents --search security are read-only inspection. vibeco update pulls the latest and reinstalls. There is also a Terminal HUD described as a real-time statusline and a dashboard for monitoring, plus an Agent Monitoring Dashboard mentioned in the v2.0 notes.
The README also claims support for Cursor, Codex CLI and OpenCode under a multi-CLI section, though it does not explain how the agent and hook layers map onto CLIs that do not share Claude Code's hook model.
Where this is the wrong tool
The README says no configuration is needed, just install and code. That is true only in the narrow sense that defaults exist. The moment you care about context cost you are choosing a profile, and the moment you care about behaviour you are choosing which hooks run. The claim of zero configuration and the existence of eleven profiles are in tension, and the README does not resolve it.
More seriously, the project asks you to install 74 TypeScript hooks that observe, filter and inject context, plus a loop that turns errors into rules, and it does not document a per-component provenance story. The counts in the badges do not match the README body in places: the badge says 296 skills while the description line says 295, and the badge says 74 hooks while the description says 73. Small drift, but it tells you the numbers are maintained by hand.
If your workflow requires every prompt-affecting component to be auditable before it runs, this is the wrong shape of tool. If you work outside Claude Code, the multi-CLI badges notwithstanding, the hook layer is the part least likely to transfer.
What a plain Claude Code setup does differently
The alternative is not another agent pack. It is Claude Code with a handful of hand-written agent files and a CLAUDE.md, which is what most teams converge on. The difference in approach is ownership: you write the roles you need, you know what each one says, and nothing rewrites them between sessions. vibecosystem's trade is the inverse. You get 138 pre-written roles and a learning loop that adapts them, and you give up line-by-line knowledge of what any given agent will do on a Tuesday.
For a solo developer on a greenfield project, hand-written agents plus the core profile are close substitutes, and the hand-written set will be smaller. Where vibecosystem pulls ahead is breadth you would not write yourself: the v2.0 notes add agents such as sast-scanner, mutation-tester, dependency-auditor and incident-responder, and v2.1.1 imported skills like factcheck-guard and ai-slop-cleaner from another project. If those specific roles match work you keep doing badly by hand, the pack earns its context cost.
Maintenance, licensing and what to check before you commit
The licence is MIT, which permits commercial use and modification; the repository does not state any additional terms, and nothing here is legal advice. The maintenance signal is the release cadence: v3.1.1, v3.2.0 and v3.3.0 all landed on 2026-04-12, with the last push to main on 2026-08-08. Three releases in one day is a burst, not a rhythm, and the README's own version notes jump from v2.4 to v3.0 to v3.4 while the releases list stops at v3.3.0, so the changelog and the release list are not in sync.
Upgrade cost is where the installer manifest matters. vibeco update pulls the latest and reinstalls, and v3.4 says ownership manifests make backups and pruning explicit. That is the mechanism that lets an upgrade remove what it previously added instead of layering on top. Before you rely on it, run the installer once on a scratch checkout and read the manifest it writes. If the manifest does not list a path the installer touched, the upgrade path is not as clean as the release note implies.
Editorial conclusion
Adopt vibecosystem if you already work inside Claude Code and want a pre-built role set without writing agent files yourself; start with ./install.sh --profile core and run vibeco effective-config before adding anything else. Do not adopt it if you need per-component provenance, or if you cannot accept a learning loop that writes rules from observed errors. Verify first: that vibeco doctor reports healthy hooks on your machine, that the core profile stays inside your context budget, and that the ownership manifest produced by the installer lists every path it touched.
Community notes