If you are still manually typing out slash commands in Claude Code, I have some bad news for you. You are living in the past. You’re basically using a flip phone in a smartphone world.
That is a bit harsh, Corn, but you are not wrong. The speed at which the Claude Code extension system has evolved is actually kind of breathtaking. We went from simple text shortcuts to autonomous agents in what feels like a weekend. I am Herman Poppleberry, by the way, and today we are dissecting the gut of Claude’s custom power-ups.
It is Episode nineteen seventy of My Weird Prompts, and we have a meaty one today. Daniel sent us a breakdown of the four key extension points in Claude Code: slash commands, skills, subagents, and plugins. He essentially wants us to clear up the massive confusion among developers about which tool to reach for and when. By the way, today’s episode is powered by Google Gemini three Flash, which is handling the scriptwriting duties for us.
I love that Daniel sent this because even for people living in the terminal, the hierarchy here is getting a bit fuzzy. People hear "plugin" and think it is a new capability, or they stick to slash commands because that is what they learned first. But there is a very specific logic to how Anthropic built this.
Alright, let’s get the prompt out there. Daniel wrote to us saying: Claude Code has become one of the most popular AI coding tools, but many users, even experienced developers, get confused by the different extension points it offers. Today, break down the four key concepts: slash commands, skills, subagents, and plugins. He mentions that slash commands are the legacy way, skills are the modern replacement with automatic invocation, subagents are for context isolation, and plugins are the distribution layer that bundles everything together. He wants us to give practical examples, call out common mistakes, and provide a mental model for deciding which one to use.
That is a perfect roadmap. There is a real hierarchy here that most people miss. If you think of Claude Code as a workshop, slash commands are like a manual screwdriver. Skills are the power tools. Subagents are specialized contractors you hire to do one specific job in the back room so they do not make a mess in your main workspace. And plugins? Plugins are just the shipping container that all those tools arrive in.
I like that. So let’s start with the manual screwdriver, the slash commands. These live in the dot claude slash commands directory, right? Just simple markdown files.
Well, not exactly—I should say, you have hit the nail on the head. They are basic. You write a markdown file, name it something like unit-test dot md, and then you have to explicitly type forward slash unit-test in the terminal for Claude to even know it exists.
It is very "command-line" in the traditional sense. It does not feel very agentic.
It is not agentic at all. That is the point. The model has no idea these commands exist until you invoke them. There is no metadata, no description for the model to read beforehand, and no way for Claude to say, "Hey, I see you just wrote a new function, would you like me to run that unit-test command?" It is purely a reactive, user-triggered shortcut.
So why are people still using them? Is it just muscle memory?
Partly muscle memory, and partly because they are incredibly easy to write. If you just want a quick template for a git commit message, a slash command is fine. But the industry is moving away from them. They are essentially deprecated in favor of skills. If you are starting a new project today, you really shouldn't be putting anything in the commands folder.
Which brings us to the "modern standard," as Daniel called it. Skills. Now, these live in dot claude slash skills, but they aren't just single files. They are directories.
This is a huge jump in capability. Each skill has a skill dot md file, but it can also have supporting scripts—Python, Shell, whatever. But the "magic" ingredient is the YAML frontmatter at the top of that markdown file. This is where you define the name, the description, and most importantly, the instructions that tell Claude when and how to use it.
This is the "automatic invocation" part that blew my mind when I first saw it. You don't have to type the command. Claude just... knows.
It is a fundamental shift in the UI. Because the description is part of the metadata, Claude reads all your available skills at the start of the session. If you tell Claude, "Hey, help me refactor this," and you have a skill with a description that says "use this tool to refactor legacy code according to our company style guide," Claude will autonomously decide to trigger that skill. It sees the intent and matches it to the tool.
That feels a bit like giving a kid a hammer and everything looking like a nail. Does Claude ever get a bit too trigger-happy with skills?
It can, but that is why the YAML frontmatter is so powerful. You have fine-grained control. You can set a property called disable-model-invocation to true. If you do that, the skill behaves like a legacy slash command—it only runs when you tell it to. But you still get the benefit of the supporting scripts and the better organizational structure. You can also define argument-hints to help the UI prompt you for the right parameters.
I saw something in Daniel’s notes about "personal" versus "project-level" skills. That seems like a big deal for productivity.
It is huge. You can put skills in your home directory—tilde slash dot claude slash skills—and they follow you everywhere. Imagine you have a specific way you like to summarize your daily work for a stand-up meeting. You write that as a personal skill, and no matter what repo you are in, Claude has that capability. Then, you use the project-level folder for things specific to that codebase—like a custom deployment script or a specialized linting rule.
So, let's say I'm a developer and I've been using a slash command to generate boilerplate for React components. If I move that to a skill, what's the immediate "aha" moment?
The "aha" moment is when you just say to Claude, "I need a new button component that handles a loading state," and instead of Claude hallucinating a random button, it says, "I am going to use the React Component Skill to ensure this matches your project's architecture." It feels like the tool is actually collaborating with you rather than just following a script.
It’s the difference between a subordinate who only does exactly what you say, and a partner who knows your workflow and anticipates what you need.
Precisely. And the configuration goes even deeper. You can specify which model should run the skill. Maybe you want the main conversation to be Claude three point five Sonnet because it is fast, but for a complex architectural refactor skill, you want it to trigger a sub-call to Claude three Opus. You can define that in the skill configuration.
Wait, so a skill can actually trigger a different model?
Yes. And it can run in a "forked context," meaning it doesn't necessarily have to drag the entire history of your current chat into the skill execution. It keeps things cleaner.
Okay, so if skills are the "how-to" for Claude, let's talk about the heavy hitters: Subagents. These live in dot claude slash agents. Daniel called context isolation their "superpower." Why is that so critical?
This is the most important technical concept for anyone building complex systems with Claude Code. Have you ever been in a long coding session where you’ve been debugging for an hour, and suddenly Claude starts forgetting what you were originally trying to do? Or it starts making weird mistakes because the chat history is full of five hundred lines of error logs?
Oh, all the time. It gets "context poisoning." The signal-to-noise ratio just tanks.
That is exactly what subagents fix. When you define a subagent in dot claude slash agents slash agent-name slash agent dot md, you are creating a specialized worker that lives in its own "clean room." When Claude delegates a task to that subagent, the subagent gets a fresh context window. All the messy exploration, the intermediate file reads, the logs—all of that stays inside the agent’s session.
So it's like if I'm building a house, and I tell my lead contractor, "Go figure out why the plumbing is leaking in the basement." The contractor goes down there, takes a bunch of measurements, talks to three different specialists, and then comes back and just tells me, "We need a new three-quarter-inch pipe." I don't need to hear the hour-long conversation he had with the plumber.
That is a perfect way to put it. The main conversation stays high-level and focused on the goal. The subagent does the "dirty work" of digging through files and logs. And just like skills, Claude can invoke these automatically. If you have a "Security Auditor" agent, and you ask Claude to "check this PR for vulnerabilities," Claude identifies the intent, sees the agent description, and spins up that specialized worker.
And these can run in parallel, right?
Yes! You could have one subagent refactoring a module, another one writing unit tests for it, and a third one updating the documentation. They all run simultaneously in their own isolated bubbles. It's multi-threading for AI agents.
That sounds like a recipe for using up a lot of tokens very quickly.
It can be, but it is actually more efficient in the long run. Because the context windows are smaller and more focused, the models are less likely to hallucinate or make mistakes that require three more prompts to fix. You are paying for precision. Plus, you can restrict the tools an agent has access to. You might give an "Auditor" agent permission to read every file in the repo but strictly forbid it from using the write-file tool. It’s a security sandbox as much as a context sandbox.
I can see developers getting confused here. When do I make a "testing skill" versus a "testing agent"? They sound similar.
This is the core of the mental model. A skill is a capability. It is a tool in your belt. You use a skill for a discrete, well-defined action that you want Claude to be able to do. "Generate a unit test for this file" is a skill. It’s a tool.
And an agent is a role.
Right. You reach for an agent when the task is open-ended, complex, or requires a lot of "thinking" that would clutter up your main chat. If you say, "Review this entire codebase and find every place where we aren't handling database connection errors properly," that is a role. That is a job for an agent. It needs focus, it needs to look at dozens of files, and it shouldn't be bothering you with every single file it reads.
So, Skill = Tool. Agent = Contractor.
Use a skill when you want Claude to have a new ability. Use an agent when you want to delegate a complex responsibility.
Okay, so we've got our tools and our contractors. Now we have the fourth piece: Plugins. Daniel says these are a "distribution layer." This sounds like the part that makes Claude Code actually shareable across a team.
Right. A plugin isn't a new technical capability in terms of how the AI thinks. It is a shipping container. A plugin is a folder with a dot claude-plugin slash plugin dot json manifest file. Inside that container, you can bundle everything we just talked about: multiple skills, multiple agents, git hooks, and even MCP—Model Context Protocol—servers.
So if I build a really cool suite of tools for working with, say, a specific AWS stack, I don't have to tell my teammates to copy-paste three different folders into their dot claude directory. I just give them the plugin.
Precisely. And the manifest file handles the versioning and the author info. But the most important technical feature of plugins is namespacing. If you have a skill called "deploy" and I have a skill called "deploy," and we both try to use them in the same project, we have a conflict.
Ah, the classic naming collision.
Plugins solve this. When a plugin is installed, its tools are prefixed with the plugin name. So it becomes slash aws-helper colon deploy. It keeps the environment clean even when you're pulling in tools from five different sources.
I’m curious about the "hooks" part Daniel mentioned. What are those doing in a plugin?
Hooks are scripts that trigger on specific events. Think of them like git hooks, but for your AI assistant. You can have a pre-commit hook that runs a specific "Linter Skill" every time you try to commit code. Or a "Post-Install Hook" that sets up the environment. It allows the plugin to be more than just a collection of tools; it can actually integrate with the lifecycle of your development process.
This really paints a picture of Claude Code moving from a "chatbot in a terminal" to a full-blown agentic operating system.
That is exactly what Anthropic is building. They are building a platform where the "user interface" is increasingly autonomous. The goal is that you shouldn't have to manage the AI; the AI should have the right tools and the right "staff" to manage the project for you.
So let's talk about the common mistakes. Daniel mentioned people are still stuck in the "slash command habit." Why is that a problem? Is it just that they’re missing out on the "proactive" help, or is there more to it?
It is the proactivity, but it is also the lack of structure. When you use a slash command, you are limited to what you can fit in a markdown file. You can't easily reference external scripts or maintain a library of examples for the model to follow. Skills allow for a much richer "developer experience" for the person writing the tool.
It’s the difference between writing a quick bash alias and writing a proper CLI tool.
That is a great analogy. The bash alias is the slash command. It’s quick, it works, but it’s fragile and hard to share. The skill is the CLI tool—it has documentation, it has structure, it has parameters.
What about the "Subagent" mistakes? I bet people are trying to use subagents for things that should just be simple skills.
Oh, definitely. People get excited about the "isolation" and start making an agent for everything. But remember, every time you spin up an agent, you are starting a new session. There is overhead there—both in terms of time and cost. If you just need a quick regex explanation, you don't need a "Regex Expert Agent." A simple skill—or even just asking Claude directly—is better.
It’s about matching the "weight" of the tool to the "weight" of the task.
Precisely. If the task requires more than, say, five or ten steps of exploration, or if it involves reading more than a dozen files, that is when you start thinking about an agent. If it is a single-shot transformation of text, keep it as a skill.
I think the most interesting part of this hierarchy is how it all ladders up. You start with a skill to solve a personal pain point. You realize it is part of a larger workflow, so you build an agent to handle the whole role. Then you realize your whole team needs this, so you package it all into a plugin.
It’s a very natural evolution. And what I find fascinating is how this changes the "skill set" of a developer. We used to talk about "prompt engineering" as just writing better instructions in a chat box. Now, "prompt engineering" is actually becoming "systems engineering." You are designing a multi-agent system with specialized tools, isolated context, and automated triggers.
It’s almost like we’re becoming managers of a small digital department.
We really are. And if you aren't using these extension points, you are basically trying to do every single job in that department yourself. You are the coder, the tester, the architect, and the intern. These tools let you delegate.
So, practical takeaways for the listeners. If I'm sitting at my terminal right now, and I've got a bunch of custom slash commands I've written over the last few months... what's my move?
Step one: Audit your dot claude slash commands folder. Anything that you use more than once a day should be migrated to a skill in dot claude slash skills. Create a folder, move your instructions into a skill dot md file, and write a really clear description in the YAML frontmatter.
And that description is what enables the "magic" automatic invocation.
Make the description something like "Use this skill when the user wants to..." and then describe the intent. You will be amazed at how much more helpful Claude becomes when it can proactively offer to use that tool.
Step two: Look for the "context killers."
Right. If you have a specific task that always seems to "break" Claude's train of thought—maybe it's a massive log analysis or a complex refactor of a legacy module—that is your prime candidate for a subagent. Create dot claude slash agents slash your-agent-name, write a system prompt in agent dot md, and give it the specific tools it needs.
And step three: If you're working on a team, start thinking in plugins.
Don't let your team reinvent the wheel. If you've built a great agent for your company's specific API, wrap it in a plugin dot json manifest and put it in a shared git repo. It makes the entire team's Claude Code instance smarter instantly.
I love the idea of a "team-wide" brain that just gets better as everyone contributes skills and agents to a shared plugin.
It’s the open-source model applied to agentic workflows. It’s incredibly powerful.
One thing that occurs to me—is there a risk of "plugin bloat"? If I install twenty different plugins, is Claude going to get confused by all the different skills and agents competing for its attention?
That is a real concern, and it's why namespacing is so important. But also, this is where the quality of your descriptions matters. If every plugin has a skill described as "helps with coding," Claude is going to have a hard time. The more specific you are in your skill and agent descriptions, the better the routing will be. It's like having twenty employees—if they all have the same job description, nobody knows who to go to. If they have very specific roles, the department runs smoothly.
So, specificity is the antidote to bloat.
Always. In the AI world, ambiguity is the enemy of autonomy.
This has been a great deep dive. I feel like I finally have a mental map of this dot claude directory. It always felt a bit like a junk drawer to me, but there is a real architecture here.
It is a very deliberate architecture. Anthropic clearly put a lot of thought into how to scale from a single user talking to a model to a team of developers using an agentic system.
Well, I think we have covered the bases. We've got the legacy slash commands, the modern skills with their automatic invocation and YAML magic, the subagents with their context isolation superpower, and the plugins as the distribution layer.
And remember that hierarchy: Plugins are the containers. Inside them, you have Skills and Agents. Skills are your tools, and Agents are your specialized contractors. If you keep those distinctions in mind, you will be miles ahead of most developers using these tools.
Before we wrap up, I want to give a shout-out to our producer, Hilbert Flumingtop. He keeps the gears turning behind the scenes.
And a big thanks to Modal for providing the GPU credits that power this show. They make the heavy lifting look easy.
This has been My Weird Prompts. If you found this breakdown of Claude Code useful, we'd love it if you could leave us a review on your podcast app. It really helps other developers find the show.
You can find all our episodes and the RSS feed at myweirdprompts dot com.
We will be back soon with more weird prompts and deep dives into the tools that are changing how we build.
Until next time.
See ya.
