Replacing Developer Docs with Claude’s Plugin Marketplace

We don’t need developer documentation anymore, and you’ll be more productive than ever 🤯

Last week Anthropic released a feature that may lead to a huge leveling up across your development team.

If you have multiple (or large) codebases with many individual systems or processes, it can be difficult to onramp a new dev. If you have one dev who needs to work on an area they never worked in, in the past this may have required discussions with other team members, or time spent clicking through and understanding what’s going on.

If your team is fast moving, there probably isn’t much documentation either.

Enter Claude Plugins

Claude Code Plugins now allow you to create a github repository with (nearly) hot swappable features to share with your team. I say nearly, because at this current time you have to restart “claude” in your terminal when enabling or disabling any plugins.

This is a big deal, because it’s already been made clear that some team members have agents and commands I don’t want or need to use. I wouldn’t want to waste my context window having these enabled either.

The new plugin marketplace feature solves these problems, and I think it enables instant context sharing across your dev team, with the most minor amount of time spent documenting areas of your codebase.

How it works

All you have to do is create a new github repository, and add a couple json files to get started

To host a marketplace, all you need is a git repository, GitHub repository, or URL with a properly formatted .claude-plugin/marketplace.json file. See our documentation for details.

To use plugins from a marketplace, run /plugin marketplace add user-or-org/repo-name, then browse and install plugins using the /plugin menu.

A powerful example

Currently at work, there is a new pipeline we made to process a new piece of logic that runs hundreds of times per second. Another dev on the team was assigned a task on this feature that was originally made mostly by myself, with this dev not even looking at any of the code until now.

This feature requires a few environment changes, and preparation commands in order to start working on it locally.

In the past, I would need to write this up, explain each step to each team member, and they may still have more questions about how different parts work.

Instead, I created a new subagent definition in markdown, this is about 1 paragraph with some bullet points.

I know what you’re already thinking… if you did that, why not explain and send this to the other developers?

Here’s a few reasons why, as demonstrated by sharing parts of this subagent definition.

Hot Swappable Subagents

The definition for this agent starts with:

“You are an expert in this area of the codebase, ensure you read and understand it fully <path to feature>”

This alone isn’t something I could say to a team member. To Claude however, it is able to read and pull all of this feature into its context, ready to go for any questions about how it works after.

In addition, I described in a bullet list, the preparation commands that need to be ran to setup the environment, and I have the subagent to tell the user what the final command is to start using this pipeline and to also offer help after running the required setup commands.

Slash Commands

The last step, I register a slash command like “/run-pipeline” inside this feature’s plugin. This command invokes the subagent directly without the developer having to know its name.

In Practice

Now that we have a plugin marketplace for our team, if someone needs to work on this feature, all I have to tell them to do is install our marketplace in their claude code, if they haven’t already. As easy as `/plugin marketplace add user-or-org/repo-name`as mentioned earlier. If your computer has access to the org / repo on github it’s able to pull it in immediately.

Next, I can mention, “enable the feature X plugin from our marketplace and run the /start-x command, it’ll configure everything and provide you all the context”

The developer will be given a recap of the step required to run the code, and be given a chance to ask any questions about the code at this point.

Summary

This feature seems small but I think it’s going to lead to a paradigm shift of internal developer communication and documentation. When building a large feature, it takes all of 10 minutes to define an agent and provide the necessary testing steps, file locations, and commands needed. The rest of the team can enable this feature plugin on the fly anytime to gain context, without extra meetings, hours spent reading code manually, or other slow processes.