Extending the Agent Without Losing the Boundary
Claude Code can be changed at several levels, but those levels do not solve the same problem. This chapter matches a need to a workflow plugin, specialized agent, project-local hook, MCP connection, SDK application, or built-in mod. The aim is not to catalogue extension folders. It is to understand what each surface changes, when it runs, who owns it, and which boundary remains outside its reach.
Choose the surface by what needs to change
A plugin is the shared packaging boundary. The repository describes plugins as extensions that can provide slash commands, specialized agents, hooks, skills, and MCP servers, with optional directories for each capability and metadata that identifies the plugin. That structure is useful because a team can distribute a coherent behavior rather than copying a prompt from one project to another. It also gives the behavior a lifecycle: somebody has to decide when it is installed, updated, trusted, and removed.
Packaging does not automatically grant authority. A plugin can describe a command or register a hook, but the surrounding Claude Code configuration still determines whether that plugin is available and what the event can do. This distinction is especially important for plugins that combine several surfaces. A workflow command may ask an agent to explore a repository, a hook may react to the resulting edit, and an MCP server may expose a remote system. The plugin is one distribution unit, but the capability path still contains separate triggers and data boundaries. Review and policy should follow those paths instead of treating the plugin name as a complete risk description.
The right choice inside a plugin depends on the kind of change. A command is a user-invoked workflow. It is a good fit when the problem has a recognizable start and a sequence of steps, such as the feature-development workflow that clarifies requirements, explores a codebase, compares designs, and reviews a result. A specialized agent is a reasoning role that can be invoked where a particular kind of analysis is needed. The feature-dev plugin’s explorer, architect, and reviewer agents divide attention rather than adding a new user-facing command for every internal task.
A skill supplies reusable guidance for a domain or activity. It can shape how a task is approached without necessarily becoming a new event-time gate. A hook is different because its trigger is part of its meaning. It reacts to a prompt, tool event, file change, or stop attempt. If the desired behavior is “warn when this kind of file is edited” or “block this command before it runs,” a hook is more direct than a long instruction asking the model to remember the rule.
MCP servers extend the tool boundary. They can make an external system or service available to Claude Code, which means the important design question is not only what the server can do but also what data and authority cross into it. An MCP connection can be the right answer when the agent must interact with a deliberately exposed service. It is the wrong answer when a prompt or local transformation would suffice and the additional system would create unnecessary credentials, network paths, or operational ownership.
An SDK application changes the boundary again. Instead of adding a behavior to an interactive Claude Code session, the team uses the Agent SDK development plugin to create a Python or TypeScript application with its own project files, environment setup, tools, prompts, sessions, and verification. This is the surface for repeatable software that will be run, tested, and deployed as an application. It should not be selected merely because an interactive workflow has become slightly inconvenient.