How to use wshobson/agents in Claude Code

The moment it pays off

You are three hours into a production incident. You do not want a general assistant. You want someone who has done incident response before, and then someone else who knows what to check in the logs.

wshobson/agents is 415 components, and that number is the problem it also solves. Nobody reads 415 anything. What you actually do is reach for one family at a time, and the families are the reason this plugin is worth installing rather than copying four files out of it.

What is inside

181 skills, 137 agents, 93 commands and one MCP server. The counts come from the plugin's own synced manifest, so the listing beside this page is always the current number.

The components are not a flat pile. They arrive in sets that were designed together:

• The parallel-work set. team-lead decomposes work into tasks with file ownership boundaries, then team-implementer, team-reviewer and team-debugger each take one lane. Seven commands drive it, from team-spawn through team-status to team-shutdown.
• The architecture ladder. c4-context, c4-container, c4-component and c4-code are the four C4 levels, and each one synthesises the level below it. You run them in order and get a documented system rather than four disconnected diagrams.
• The red-green-refactor set. tdd-red, tdd-green and tdd-refactor are separate commands on purpose, with tdd-cycle for the whole loop and a tdd-orchestrator agent above them.
• Ten SEO agents, which is the largest single family in the collection.
• Framework specialists rather than one generic coder: django-pro, fastapi-pro, graphql-architect, temporal-python-pro.
• Operations: deployment-engineer, devops-troubleshooter, observability-engineer, performance-engineer, cloud-architect.
• Deep skill sets behind those agents, including event sourcing (cqrs-implementation, event-store-design, saga-orchestration, projection-patterns) and accessibility (wcag-audit-patterns, screen-reader-testing).

Install it

The install commands are on the listing, derived from the plugin's own synced manifest rather than typed here. A guide that copies a command has no way to know when the author renames their marketplace. The listing does.

Which of the 415 you actually use

This is the only question the component list cannot answer for you, so here is the honest version: you adopt a family, not an item.

Pick the one that matches the work in front of you.

• Shipping a feature across several files at once, and tired of serialising it? The team-* set is the reason to be here.
• Inheriting a system nobody documented? Run the four c4-* agents in order.
• Writing Django, FastAPI or GraphQL? Take the one framework specialist and ignore every other agent entirely.
• Standing up monitoring, or in the middle of an incident? The operations five.

The rest stay installed and silent until their moment. That is the point of a bundle this size: the cost of an agent you never call is zero, and the cost of not having it at 2am is not.

When you should not use it

If you want three agents, take three agents. This is a large collection by an author who works across many stacks, and installing it to get frontend-developer alone is more surface than you need.

It is also not a routing layer. The components are here and they are good, and choosing between them is still your job. If what you want is the choosing to happen for you, that is a different kind of plugin and the listing will tell you which ones do it.