Reviewing everything-claude-code: 41K Stars, But Should You Install It?
Reviewing everything-claude-code: 41K Stars, But Should You Install It?
everything-claude-code is the most popular Claude Code plugin, with 41K+ stars and 5K+ forks. It ships 13 agents, 31 commands, 29 skills, and multi-language rules. Created by an Anthropic hackathon winner, it’s been the go-to recommendation in every “how to set up Claude Code” guide.
I dug through every agent definition, command, rule file, and skill to answer the question: is the hype justified?
What It Actually Contains
Agents (13 total)
Each agent is a markdown file that defines a subagent’s role, tools, and model. The core set:
| Agent | Model | What It Does |
|---|---|---|
planner | Opus | Breaks features into phased implementation plans. Won’t write code until you confirm. |
code-reviewer | Opus | Runs git diff, reviews changes against a checklist (security, quality, performance). |
security-reviewer | Opus | OWASP Top 10 analysis with concrete vulnerable/fixed code examples. |
tdd-guide | Opus | Enforces red-green-refactor cycle. Includes mock patterns for Supabase, Redis, OpenAI. |
architect | Opus | System design decisions — database schema, service boundaries, API contracts. |
build-error-resolver | Sonnet | Reads build errors, applies fixes iteratively. |
e2e-runner | Sonnet | Playwright-based end-to-end test writer and runner. |
refactor-cleaner | Sonnet | Dead code detection and cleanup. |
doc-updater | Sonnet | Syncs documentation with code changes. |
go-reviewer | Opus | Go-specific code review (idioms, error handling, concurrency). |
python-reviewer | Opus | Python-specific review (PEP 8, type hints, Django patterns). |
database-reviewer | Opus | Schema review, query optimization, migration safety. |
go-build-resolver | Sonnet | Go-specific build error resolution. |
Verdict: The agent definitions are well-structured. The planner’s “confirm before coding” gate is a genuinely useful pattern — it prevents Claude from charging ahead on a misunderstood requirement. The security reviewer includes concrete code examples for 10 vulnerability types, not just a checklist. The language-specific reviewers (Go, Python) are a nice touch that generic configs miss.
The catch: Every Opus agent costs significantly more tokens per invocation. The code-reviewer is set to Opus and marked as “MUST BE USED for all code changes” — that’s expensive for a renamed variable. There’s no guidance on when to skip a review.
Commands (31 total)
Slash commands that invoke agents or workflows:
Core workflow:
/plan— Activates the planner agent/tdd— Starts a TDD cycle/code-review— Triggers code review/build-fix— Runs build error resolver/e2e— Runs E2E test agent/verify— Verification loop
Multi-agent orchestration (new in v1.4):
/multi-plan— Parallel planning across concerns/multi-execute— Parallel implementation/multi-backend//multi-frontend— Split by stack layer/orchestrate— Full PM2-based multi-agent workflow/pm2— Process manager for concurrent agents
Continuous learning:
/instinct-status— View learned patterns/instinct-import//instinct-export— Share patterns between machines/evolve— Cluster instincts into reusable skills/learn— Manual pattern capture
Utility:
/skill-create— Generate skills from git history/checkpoint— Save current state/sessions— Session management/update-docs//update-codemaps— Documentation sync
Verdict: The core workflow commands (/plan, /tdd, /code-review, /build-fix) are the strongest part of the plugin. They give structure to what would otherwise be ad-hoc prompting. The multi-agent orchestration commands are ambitious but assume PM2 is installed and configured — that’s a dependency the README mentions but doesn’t emphasize enough.
The continuous learning system (/evolve, /instinct-*) is the most original feature. It watches your sessions, extracts patterns with confidence scores, and gradually builds personalized skills. Whether it works well in practice depends on session volume — you need enough data for meaningful patterns to emerge.
Rules (4 directories)
1
2
3
4
5
rules/
common/ # 8 files — language-agnostic
typescript/ # TypeScript/JS specific
python/ # Python specific
golang/ # Go specific
The common/ rules are the same ones that appear in chris2ao/claude-code-config (that repo copies these). They cover coding style, git workflow, testing, security, performance, patterns, hooks, and agent orchestration.
Verdict: The multi-language split is smart. Loading Go rules when you’re writing TypeScript wastes context. The manual installation requirement (the plugin system doesn’t distribute rules) is clunky but necessary — rules need to live in ~/.claude/rules/ and the plugin can’t write there.
Same problems as the copied version: The performance.md rule references “Haiku 4.5,” “Sonnet 4.5,” and “Opus 4.5” — none of which are actual model names. The current lineup is Haiku 3.5, Sonnet 4, and Opus 4. Claude Code handles model routing internally anyway; a rule file doesn’t change which model runs your subagents.
Skills (29 total)
Skills are workflow definitions — methodology steps and domain knowledge. Highlights:
Framework-specific (most useful):
django-patterns,django-security,django-tdd,django-verificationspringboot-patterns,springboot-security,springboot-tdd,springboot-verificationgolang-patterns,golang-testingpython-patterns,python-testingpostgres-patterns,jpa-patterns,clickhouse-io
Workflow skills:
tdd-workflow— Full TDD methodologyverification-loop— Iterative check-and-fixeval-harness— Evaluation frameworkstrategic-compact— Context window managementcontinuous-learning-v2— The instinct-based learning system
Verdict: The framework-specific skills are where this plugin genuinely earns its value. If you’re writing Django or Spring Boot, having pre-built security checklists and testing patterns specific to those frameworks saves significant prompting. The strategic-compact skill (knowing when and how to compact context) is a practical meta-skill that most configs ignore.
Hooks
The hooks.json is comprehensive:
| Hook Type | What It Does |
|---|---|
| PreToolUse | Forces dev servers into tmux, reminds about long-running commands, gates git push with review |
| PostToolUse | Auto-formats JS/TS with Prettier, validates TypeScript syntax, warns on console.log, logs build status |
| PreCompact | Saves state before context compression |
| SessionStart | Loads previous context, detects package manager |
| SessionEnd | Persists state, evaluates patterns |
| Stop | Checks modified files for leftover debug statements |
Verdict: The hooks are thoughtful. Auto-formatting with Prettier after every edit is a workflow saver. The console.log warning catches a common mistake. The tmux enforcement for dev servers is opinionated but prevents the “where did my server output go?” problem. The pre-compact state save is clever — without it, you lose context when Claude compresses the conversation.
Caveat: These hooks assume a JavaScript/TypeScript workflow (Prettier, TypeScript validation). If you’re writing Python or Go, several hooks are irrelevant noise.
What’s Good
1. The agent architecture is well-designed. Each agent has a clear scope, specific tools, and an appropriate model assignment. The planner’s confirmation gate and the security reviewer’s concrete vulnerability examples are standout patterns. This is how you should structure agents — focused, not kitchen-sink.
2. The continuous learning system is genuinely novel. Most Claude Code configs are static. This one watches your sessions, builds confidence-scored patterns, and evolves them into reusable knowledge. It’s the most ambitious feature and the one most likely to improve over time.
3. Framework-specific skills fill a real gap. Generic “write good code” rules are near-useless. Django-specific security patterns, Spring Boot testing workflows, and Go concurrency idioms actually change Claude’s output in measurable ways.
4. The hooks prevent real mistakes. Auto-formatting, debug statement detection, and git push gating are the kind of automation that pays off daily.
5. The /plan -> /tdd -> /code-review pipeline. This structured workflow is the plugin’s core value proposition. It turns Claude from a reactive tool into a process-driven development partner.
What’s Not Good
1. Context window cost is massive. 13 agents + 29 skills + 8 rule files + 31 commands = a lot of token overhead. The README itself warns: “Don’t enable all MCPs at once. Your 200k context window can shrink to 70k with too many tools enabled.” The same applies to the plugin itself. You’re not using all 31 commands in one session, but they’re all loaded.
2. The model names are wrong. performance.md references Haiku 4.5, Sonnet 4.5, Opus 4.5. These don’t exist. The actual models are Haiku 3.5, Sonnet 4, and Opus 4. This undermines trust in the technical accuracy of the rules.
3. Everything defaults to Opus. Five of the 13 agents specify model: opus. The code-reviewer is marked as mandatory for all code changes and runs on Opus. That’s the most expensive model for what might be a one-line change. There’s no tiered approach — small changes should use Sonnet, complex reviews Opus.
4. JavaScript/TypeScript bias. The hooks auto-format with Prettier, validate TypeScript syntax, and warn on console.log. If you’re writing Python or Go, these do nothing useful but still fire. The multi-language rules help, but the hooks don’t adapt.
5. Rules require manual installation. The plugin system can distribute agents, commands, and skills, but not rules. You have to manually cp -r rules/common/* ~/.claude/rules/. This is a Claude Code platform limitation, but the README should make this more prominent — it’s buried in a bullet point.
6. PM2 dependency for multi-agent orchestration. The /orchestrate, /pm2, and /multi-* commands require PM2 (a Node.js process manager) installed globally. That’s a significant dependency for what’s marketed as a plug-and-play plugin.
7. The “MUST BE USED” tone is counterproductive. The code-reviewer agent says “MUST BE USED for all code changes.” The testing rule says “No code without tests. Tests are not optional.” These absolute mandates break down the moment a user needs to quickly fix a typo. Overly rigid rules teach Claude to be inflexible rather than context-aware.
Who Should Use It
Yes, install it if:
- You work primarily in TypeScript/JavaScript and want automated formatting and review
- You build with Django, Spring Boot, or Go and want framework-specific patterns
- You want the structured
/plan->/tdd->/code-reviewworkflow - You’re interested in the continuous learning system and generate enough sessions to feed it
Skip it if:
- You work in languages it doesn’t cover (Rust, C#, Swift, etc.)
- You’re concerned about context window overhead
- You want a lightweight setup — this is the opposite of minimal
- You don’t use Node.js and can’t install PM2
Cherry-pick from it if:
- You want specific agents (planner, security reviewer) without the full package
- You like the hook patterns but need to adapt them for your stack
- You want the rule structure but with corrected model names and less rigid mandates
The Bottom Line
everything-claude-code is a legitimately impressive piece of work. 13 well-structured agents, a novel learning system, and framework-specific skills set it apart from every other Claude Code config. The /plan -> /tdd -> /code-review pipeline is a genuinely better way to work with AI-assisted development.
But it’s also bloated. 31 commands when you’ll use 5-8 regularly. Opus-tier agents for trivial reviews. Wrong model names in the rules. JavaScript-centric hooks in a “multi-language” plugin. It tries to be everything for everyone and ends up being too heavy for most.
The best approach: install it, use the core workflow commands and the agents relevant to your stack, and disable or remove everything else. The parts that work, work extremely well. There’s just too many parts.