Best free Claude Code agent collections (and what to watch for)

If you want free Claude Code subagents, three open-source collections cover most of what you need: wshobson/agents, wshobson/commands, and VoltAgent/awesome-claude-code-subagents. All three are MIT licensed, written by people who clearly use them, and good enough that you can copy files into .claude/agents/ or .claude/commands/ and get value the same day.

The catch is that a big collection isn't the same as a working setup. I went through all three repos file by file while building a curated kit, and the same handful of problems kept coming up: pinned models, agent names that only exist inside one plugin, duplicates, and descriptions too vague for Claude to delegate on. This post covers what each collection is good for, then the things to check before you install anything.

The three collections worth knowing

wshobson/agents

wshobson/agents by Seth Hobson is the largest of the three. It's organized as a plugin marketplace: each plugin bundles related agents, commands (workflows), and skills around one area, like backend development, security, or a specific language. You install the plugins you want rather than dumping everything into one folder.

What I like about it:

• Breadth. Most languages, frameworks, and ops areas have a specialist.
• Plugin grouping keeps related pieces together, so a workflow ships with the agents it calls.
• It's actively developed and, at the time of writing, targets several coding tools besides Claude Code. Check the README for the current list.

If you only look at one collection, start here.

wshobson/commands

wshobson/commands is the earlier slash command collection from the same author, split into workflows (multi-step orchestrations that hand work to several agents) and tools (single-purpose commands like scaffolding an API or running a security scan).

At the time of writing the repo is marked archived, with new work moved into the plugin marketplace in wshobson/agents. The commands are still worth reading. They're some of the best examples around of how to structure a long command prompt, and many of them adapt cleanly to your own .claude/commands/ folder. If you're new to writing commands, the slash command guide covers $ARGUMENTS, frontmatter, and the rest of the format.

VoltAgent/awesome-claude-code-subagents

VoltAgent/awesome-claude-code-subagents is organized by category instead of by plugin: core development, language specialists, infrastructure, quality and security, data and AI, developer experience, business, and so on. Each agent is a standalone Markdown file, which makes it the easiest collection to browse and cherry-pick from.

It's a good fit when you want one or two specific roles (say, a Postgres specialist and an accessibility reviewer) without adopting a whole plugin structure. The repo also offers its own install options; check the README for the current method.

Quick comparison

Together, when I counted them for curation, the three repos had 712 items across roughly 90 plugins. That's far more than any one project needs, which is where the problems start.

What to watch for

None of these are criticisms of the authors. They're what happens when hundreds of files are written over time, for different setups, and then copied into a context they weren't designed for. Every one of these showed up in real files I imported.

Hard-coded models in frontmatter

Subagent frontmatter supports an optional model field. Many collection agents pin it:

---
name: architect-reviewer
description: Reviews system design changes for architectural consistency.
model: opus
---

Of the agents I imported, 76 had a hard-coded opus, sonnet, or haiku. That matters for three reasons:

• Cost. An agent pinned to the most expensive model burns through usage every time Claude delegates to it, even for small tasks.
• Availability. A pinned model may not be what your plan or setup gives you, or what you want to pay for.
• It overrides your choice. You picked a model for the session. A pinned agent quietly ignores that.

The fix is one line. Set model: inherit so the agent uses whatever the main conversation uses, or delete the model line. Pin a model only when you've decided a specific agent needs one.

Plugin-scoped agent names

This one is subtle and it fails silently. Commands and workflows often say things like "use the backend-architect agent, then hand off to the test-automator agent." Inside the original plugin, those names exist. Copy the command on its own, or install agents from a different plugin, and the names point at nothing.

Claude doesn't throw an error. It just does the work in the main thread or picks something close, and the hand-off you thought you were getting never happens. I found 13 imported commands that referenced agents by names that only existed inside their original plugin.

The fix: after installing, list the agents you actually have and make sure every name a command mentions is on that list. Rename the reference to a real installed agent, or install the missing one.

ls .claude/agents ~/.claude/agents 2>/dev/null | sed 's/\.md$//' | sort -u

Duplicates with different names

Across three collections you'll find the same role written three ways: a code-reviewer, a senior-code-reviewer, and a code-review-expert, each with a slightly different description. Claude now has to choose between them on every review request, and the choice can change from session to session. Pick one per role and delete the rest.

Inconsistent formats

Some files have rich frontmatter, some have only name and description, some put tool lists in different styles, and a few have names that don't match the file name. Claude Code is forgiving, but inconsistency makes auditing harder and makes it easy to miss a bad field. Normalize: lowercase hyphenated name that matches the file name, a clear description, an explicit tools line where it makes sense.

Too many agents, vague descriptions

Claude decides delegation from the description field. If you install 150 agents and half of them say "Expert in X. Use for X tasks," you've made routing harder, not easier. More agents also means more names and descriptions in play when Claude decides whether to delegate.

A useful description says when to use the agent and what it returns:

---
name: migration-reviewer
description: Use proactively after any change to files in db/migrations. Checks for locking operations, missing down migrations, and data loss. Returns a list of issues with file and line.
tools: Read, Grep, Glob
---

If you can't tell two agents apart from their descriptions, Claude can't either. The subagents guide goes deeper on writing descriptions that trigger reliably.

Tool permissions broader than needed

If tools is omitted, the agent inherits all tools, including Bash and file edits. That's fine for an implementer. It's not what you want for a reviewer or researcher that should only read. Give read-only roles Read, Grep, Glob, and add Bash only where the agent actually needs to run commands.

A checklist for auditing any agent you install

Run through this for every collection, including paid ones:

1. Model. Is model: pinned? Change to inherit or remove unless you mean it.
2. Name. Lowercase, hyphenated, matches the file name, not a duplicate of something you already have.
3. Description. Says when to use it and what it returns. Specific enough to tell it apart from neighbors.
4. Tools. Narrowest set that works. Read-only roles stay read-only.
5. References. Every agent name mentioned in your commands exists in .claude/agents/ or ~/.claude/agents/.
6. Body. Read the system prompt once. Remove instructions that conflict with your CLAUDE.md or assume a stack you don't use.
7. Count. Fewer, sharper agents beat a huge pile. Delete what you won't use.

Some quick one-liners for the first and fifth checks:

# Agents with a pinned model
grep -Hn '^model:' .claude/agents/*.md | grep -v 'inherit'

# Agents that inherit every tool (no tools: line)
grep -L '^tools:' .claude/agents/*.md

# Agent names mentioned in commands that aren't installed
grep -ohE '[a-z]+(-[a-z]+)+ (agent|subagent)' .claude/commands/*.md \
  | awk '{print $1}' | sort -u \
  | while read n; do [ -f ".claude/agents/$n.md" ] || [ -f "$HOME/.claude/agents/$n.md" ] || echo "missing: $n"; done

The last one is a heuristic. It catches the common "use the X agent" phrasing, not every way a command can name an agent, so skim the output and the commands themselves.

How SlashKits curated them

This is the work I did for SlashKits, and I want to be clear about it: everything above you can do yourself, for free, with the original repos and the checklist. The kit exists to save you the afternoon (realistically, several afternoons) of doing it.

What the curation involved:

• Picked 211 of the 712 items, dropping duplicates and roles that overlapped.
• Normalized naming so each role has one clear name and file.
• Set models to inherit. All 76 pinned agents now follow your session's model.
• Rewired the 13 commands that called plugin-only names so they point at agents that are actually installed.
• Added a routing file that tells Claude which agent handles what, imported from CLAUDE.md (and referenced from AGENTS.md for Codex).
• Kept credit and a record. The MIT licenses and authors are listed in THIRD_PARTY_NOTICES, and a manifest records every change made to every imported file, so you can diff against the originals.

On top of the curated set, there are a few original pieces, like a tech-lead that plans and assigns work and a shipper agent that runs your tests, typecheck, lint, and build before returning SHIP or BLOCK. Pricing is on the pricing section.

If you'd rather build your own set, start with wshobson/agents for breadth, pull individual specialists from VoltAgent's list, read wshobson/commands for workflow ideas, and run the checklist before you trust any of it. Whichever way you go, these authors did the hard part by writing and sharing them. Star the repos.