Plugins: Packaging Scattered Configurations with One Click
📚 Series Navigation: The previous post [23 Subagents] taught you how to build a dedicated assistant by hand. But did you notice a problem? Good things like subagents, commands, skills, and hooks are all scattered pieces configured "one by one." This article teaches you how to package them into plugins: install with one click, stop with one click, and directly grab off-the-shelf full packages built by others from the "plugin marketplace."
Brothers, today we are going to talk about how to package a bunch of scattered configurations with one click. Speaking of which, have you ever encountered this scenario: You worked hard to configure a set of "subagent + hook + MCP" for the team, and then one day a new colleague arrived. You explained it to him for half an hour—"Put this file in agents/, add that hook to settings.json, and oh, don't forget .mcp.json"—and after you finished, you found out he still missed a spot, and it ran differently from yours. This isn't anyone's fault; scattered piece management is just like this: the more scattered the configuration, the easier it is to miss things through verbal instructions.
Looking back at what we've accumulated over the previous articles: Article 18 wrote CLAUDE.md, Article 22 configured an MCP server, Article 23 built a subagent, and skills and hooks were interspersed in between. Each is easy to use individually, but they are all scattered—subagents are placed in agents/, hooks are written in settings.json, and MCP is configured in .mcp.json, scattered across several files.
Here comes the problem: If you worked hard to configure this set in project A and want to reuse it in project B, you have to copy it file by file. If a new colleague in the team wants this set of configurations, you have to explain the directory structure verbally, and it's easy to omit something. Managing scattered pieces is tiring and prone to errors.
To put it bluntly, plugins are Claude Code's official answer to this problem: Packaging scattered pieces like commands, subagents, skills, hooks, and MCP servers into a package that can be distributed as a whole and started/stopped with one click. This article will thoroughly explain "what a plugin is, how to get readymade ones from the marketplace, and how to manage them."
After reading this article, you will get:
- A clear table explaining exactly what plugins package and how to choose between them and "scattered configurations"
- The two-step logic of the "plugin marketplace": add the marketplace first, then install the plugin; you can just copy the commands to use them
- Hands-on installation of a plugin from the official demo marketplace and running the commands it brings, with expected output provided throughout
- What a plugin directory looks like (
plugin.json+ various component folders), so you can follow it when you want to package things yourself - The "trust barrier" you must pass before installing third-party plugins; don't treat unfamiliar plugins as harmless software
01 Understand First: What Exactly is a Plugin
Let's give the conclusion first: A plugin is a "self-contained folder" that packages the extensions you learned earlier (skills, subagents, hooks, commands, MCP servers) together, allowing them to be installed, stopped, and distributed as a whole.
Why do we need it? Because scattered configurations have three unavoidable pain points: troublesome cross-project reuse, relying on manual effort for team sharing, and being unable to track version updates. If you configure a subagent and hook in one project and want to move them to another, you can only manually copy and paste them; if you want to share them with a colleague, you have to explain clearly where each file goes. A plugin puts this whole set "into a box"; you just move the whole box or hand the whole thing to someone else.
Analogy: Browser Extension Store. You want to add an ad blocker, translation, and screenshots to Chrome—you don't need to write code or modify configurations yourself, just go to the extension store and click "Install", and a whole set of functions is added in. If you don't want it anymore, click "Remove" for a clean uninstall. Claude Code's plugins follow this logic: browse the marketplace, install a whole set of functions with one click, without needing to configure them manually one by one; it turns extensions that used to be scattered across several files into an entry in the store that can be directly "installed/uninstalled".
The official documentation explains the trade-offs between "plugins" and "scattered configurations" very clearly. I've condensed it into a table for you:
| Dimension | Scattered Configuration (.claude/ directory) | Plugin |
|---|---|---|
| Best Suited For | Single-project personal use, personal workflow, rapid prototyping | Team/community sharing, cross-project reuse, versioned releases |
| How to Share | Manually copy files to others | Via marketplace, others install with one click using /plugin install |
| Skill Name | Short, e.g., /hello | With namespace, e.g., /my-plugin:hello |
| Version Management? | No, users can't be notified of changes | Yes, users receive updates if a version number is set |
The decision logic in this table is simple: For casual use in a single project, scattered is enough; if you need to share it with others, move it across projects, or update it, then use a plugin. Officials also recommend "using .claude/ scattered for rapid iteration first, then converting it to a plugin when ready to share"—don't over-engineer by creating a plugin for a one-off configuration right from the start.
There's a point here that confuses beginners the most, which must be clarified first: Skill names in plugins always come with a "namespace". If you write a hello skill in a plugin called my-plugin, when you call it, it is not /hello, but /my-plugin:hello.
💡 One-sentence summary: A plugin packages skills, subagents, hooks, commands, and MCP servers into a box that can be installed/uninstalled as a whole; scattered is fine for personal use, but if you need to share, reuse, or update, package it into a plugin.
02 Why Packaging into One is Better than Keeping it Scattered
The previous section talked about "what it is", and this section adds a point on "why it's worth it"—because just knowing the concept, you might still feel "manually copying a few files isn't a big deal."
The real gap lies in three areas. Combined with specific scenarios, you'll understand.
First, cross-project reuse. Imagine you always keep a set of "git commit workflow" configurations—a skill that generates standardized commit messages, and a hook that automatically runs linting before a commit. In the early days, this set was scattered. When switching to a new project, you had to copy the contents in skills/ and settings.json one by one. Once you missed copying the hook part, the new project wouldn't run lint before committing, and a formatting error might sneak in. After packaging it into a plugin, in the new project, a single /plugin install command gets everything ready, and you'll never miss anything.
Second, team sharing. Sharing scattered configurations with colleagues basically relies on "copy this folder, put it under .claude/agents/, and remember to add that hook to the settings"—a bunch of verbal instructions, and the other person will most likely configure it wrong. Plugins are different: You publish it to a marketplace (even a private repository within the company), colleagues install it with one command, and the configurations are exactly the same, completely avoiding the "it runs on my machine but not yours" situation.
Third, version updating. This is the most fatal shortcoming of scattered configurations. When scattered configurations are changed, people who have used them don't know at all, and you have to notify them one by one. Plugins can carry version numbers; when you publish a new version, users will automatically get the latest one when updating; officially they even specifically made "automatic updates"—the official marketplace is turned on by default, and third-party marketplaces are turned off by default (this design makes a lot of sense: you can automatically receive updates from your own people, but outsiders' updates require your active consent).
Analogy: The relationship between a mobile App and an App Store. You installed an App, it has a new version, the App Store pushes "update available" to you, and you upgrade with one click without having to redownload the installation package yourself. A plugin to the marketplace is like an App to the App Store—installation is one-click, and updates flow down through the marketplace; you don't need to manually move them.
Let's compare the gap between scattered configurations and plugins on these three things:
| What you need to do | ❌ Scattered Configuration | ✅ Plugin |
|---|---|---|
| Move to a new project | Manually copy each file, easy to miss | A single /plugin install command |
| Share with colleagues | Verbally explain where to put them and how to configure | Publish to a marketplace, others install with one command |
| Push updates | Can't notify, relying on shouting manually | Carries a version number, users update automatically/manually |
To be honest, you won't deeply feel the benefits of plugins for a single person in a single project; but once there are more people and more projects, scattered configurations start to drag you down. I also completely switched to plugins after leading a team—previously, setting up the environment for newcomers required pulling someone to the screen and explaining file by file "put this in agents/, add that hook to settings", wasting half a morning, and someone always missed a spot. After packaging it into a plugin and hosting it in the internal repository, newcomers can install it all with one command, their configurations are exactly the same as mine, and we've never had the "it runs on my machine but not yours" problem again.
💡 One-sentence summary: The true value of a plugin lies in "scale"—cross-project reuse, team sharing, and version updates. These three things all rely on manual effort in scattered configurations, whereas a plugin handles them all with a single command; the more people and projects there are, the wider this gap becomes.
03 Plugin Marketplace: Add the "Store" First, Then Install the "App"
Now that we know what a plugin is, the next question is: Where do I get plugins built by others? The answer is the "plugin marketplace".
Here is the most critical realization in this article, where beginners get stuck the most: Using the marketplace is a "two-step" process, not a "one-step" process.
- Step 1: Add the marketplace. "Register" a marketplace with Claude Code so it can browse what plugins are inside. Note: Not a single plugin is installed in this step; it just lets you see the shelves.
- Step 2: Install the plugin. Pick what you want from the shelves and install it individually.
Analogy: Installing a new "App Store" on your phone. In addition to the built-in store on your phone, you can also install third-party app stores—but "installing this store" does not mean "installing the Apps inside". The store just lets you go in, browse, and see its entire collection; which App you specifically want, you still have to click in and download individually. The plugin marketplace is exactly this kind of "App Store": adding it allows you to browse, but which plugin to install is a separate matter.
Once you clearly understand these "two steps", the following commands will flow smoothly. Let's first look at adding a marketplace—the official documentation provides several sources, and the most common is adding from GitHub:
/plugin marketplace add owner/repoJust replace owner/repo with the actual GitHub repository name (for example, the official demo marketplace is anthropics/claude-code). In addition to GitHub, a marketplace can also be added from a Git URL (GitLab, Bitbucket, self-hosted are all fine), a local path, or a remote URL. The official documentation lists how to write them, but beginners just need to remember GitHub, which is the most common.
After adding the marketplace, use this command to install the plugin:
/plugin install plugin-name@marketplace-nameWhat follows @ is the marketplace name, which means "install this plugin from this marketplace." For example, to install the GitHub integration from the official marketplace:
/plugin install github@claude-plugins-officialWe must specifically mention the official built-in marketplace here: claude-plugins-official. You don't need to add it manually—it's there as soon as you start Claude Code. Inside is a batch of plugins curated by Anthropic (external integrations like GitHub, GitLab, Slack, Figma, Sentry, as well as LSP plugins for code intelligence, security review plugins, etc.). So if you want to install an official plugin, skip the "add marketplace" step and just run install directly.
💡 One-sentence summary: Using the marketplace is always the two steps of "add marketplace first, then install plugin"—
/plugin marketplace addto add shelves, and/plugin install xxx@marketplace-nameto place an order; except for the official marketplaceclaude-plugins-official, which is built-in and can be installed directly out of the box.
04 The Three Marketplaces and What They Do
Several marketplace names appeared in the previous section, which can easily confuse beginners. This section will clarify the three marketplaces maintained officially, so you'll know what they are when you see their names.
Analogy: Three malls with different positionings in the same city. One is a brand direct-sale flagship store (the goods are officially curated), one is an open hypermarket (third parties come to set up stalls, but they pass security checks before entering), and there is also a temporary sample showroom (specifically displaying samples to show you the effects). Claude Code's three official marketplaces correspond exactly:
| Marketplace | Command to Add It | Positioning | What's Inside |
|---|---|---|---|
claude-plugins-official (Official) | Built-in, no need to add | Official selection | Plugins curated by Anthropic, the most stable |
claude-community (Community) | /plugin marketplace add anthropics/claude-plugins-community | Third-party submissions, passed automated review | Community-contributed plugins, each pinned to a specific commit |
claude-code-plugins (Demo) | /plugin marketplace add anthropics/claude-code | Official examples | Sample plugins showcasing plugin capabilities |
Let's make a few key points clear:
The official marketplace is the most stable but not open for application. Anthropic decides for itself which plugins to include. The contents are carefully selected, and the probability of stepping into pitfalls is the lowest. The common goods you want for daily use—GitHub integration, LSPs for various languages, security reviews—are basically all here.
The community marketplace is open, but has a threshold. After a third-party plugin is submitted, it has to pass Anthropic's automated validation and security screening to get in, and each plugin is "pinned to a specific commit"—meaning what you install is the version during the review, and the author cannot secretly swap the content. It needs to be added manually, and after adding, it is installed using the name claude-community.
The demo marketplace is for learning. It holds samples "showcasing what the plugin system can do," and the hands-on experiment in the next section will use it for practice. It also needs to be added manually.
Recommended order of access: Prioritize the official marketplace; if it's not there, go to the community marketplace to find it. If you find one, look at the homepage and the permissions it requires before installing. The demo marketplace is generally only used for teaching or testing—its positioning is a sample, not a production plugin for your daily use.
💡 One-sentence summary: The built-in official marketplace is the most stable, the community marketplace needs manual addition but has passed security checks, and the demo marketplace is a learning sample; browse the official one first for daily needs, go to the community if it's out of stock, and use the demo one for practice.
05 Installing a Plugin: What Exactly is Brought In
When you hit /plugin install, what exactly enters your environment? This section will make it clear, so you don't end up confused after installing, asking, "Then what, how do I use it?".
A plugin might bring in these types of components, and the "trigger method" for each type is different, which is the key:
| Component | How to use after installation |
|---|---|
| Skills / Commands | Become namespaced commands like /plugin-name:skill-name, which you type manually or Claude calls automatically |
| Subagents | Appear in the /agents list, Claude automatically assigns them based on tasks, and you can also select them manually |
| Hooks | Automatically triggered on corresponding events (like after modifying a file), you don't need to manage them |
| MCP server | Starts automatically, and its tools are mixed directly into Claude's toolbox ready for use |
| LSP server | Gives Claude real-time code intelligence (jump to definition, find references, instant errors); requires separate installation of language server binaries |
See the pattern? Some are "you actively call them" (skills, commands), and some are "they do it automatically" (hooks, MCP, LSP). So after installing a plugin, you must know what types of things it brings to know how to use it.
The good news is, the new version of Claude Code lists these for you before you install. If you click on a plugin's details in the /plugin interface, there will be a "Will install" block, listing the commands, agents, skills, hooks, MCP, and LSP servers the plugin brings; it also provides a "Context cost" estimate—telling you roughly how many tokens this plugin will stuff into your context window per turn.
I need to say more about this "Context cost"; it is very important. Recall the context management discussed in Article 19: every component brought by a plugin will occupy a piece of space on your workbench. Installing too many plugins means before you even start working, a large chunk of context is occupied by various skill descriptions and MCP tool definitions. You must check this estimate before installing a plugin; a few hundred tokens is fine, but for thousands you must weigh "do I really need this". Installing a bunch of unused plugins to waste context is a common newbie mistake.
There's another detail: After installing a plugin, remember to run /reload-plugins to make it take effect without restarting Claude Code. Installing, stopping, and enabling plugins in the middle of a session all rely on this command to refresh:
/reload-pluginsAfter running, it will tell you how many plugins, skills, agents, hooks, plugin MCP servers, and LSP servers are currently loaded.
💡 One-sentence summary: Components brought by plugins are divided into two categories: "you actively call them" (skills/commands) and "they do it automatically" (hooks/MCP/LSP); look at the "Will install" list and context cost in the details before installing, and run
/reload-pluginsto take effect after installing.
This diagram draws the two main threads of this article together: on the left is the two-step process of "add marketplace → install plugin", and on the right are the five types of components (skill, subagent, hook, MCP server, LSP server) packaged in a plugin box, and whether they are "you actively call them" or "they do it automatically" after being brought in.
06 Hands-on: Add a Marketplace, Install a Plugin, and Use It
All talk and no practice is useless. Below, I will guide you to add a marketplace from the official demo marketplace, install a real plugin, and run the commands it brings, without relying on any complex environment—just copy along. We are installing commit-commands named in the official documentation—a plugin that adds skills to the git workflow.
Step 1: Start Claude Code and add the demo marketplace
Go into any directory and start Claude Code:
claudeAfter entering, type in the input box (this is the first step of the "two steps"—adding the marketplace):
/plugin marketplace add anthropics/claude-codeExpectation: Claude Code downloads the directory of this marketplace and prompts that the marketplace was added successfully. At this point, you have goods on your "shelves", but no plugins have been installed yet.
Step 2: Open the plugin manager and browse around
Type:
/pluginExpectation: An interface pops up with four tabs—Discover / Installed / Marketplaces / Errors; use the Tab key to switch back and forth (Shift+Tab to switch back). Switch to the "Discover" tab, and you can see those sample plugins in the demo marketplace you just added. Seeing commit-commands in the list = the marketplace was added correctly.
Step 3: Install the commit-commands plugin
You can click on it in the interface to choose the installation scope, or you can install it directly via the command line (this is the second step of the "two steps"):
/plugin install commit-commands@claude-code-pluginsNote that after @ is claude-code-plugins—this is the internal name of this demo marketplace (not anthropics/claude-code you wrote when adding the marketplace, which is the repository address). During installation, it will ask you to choose a scope:
- User scope (default): You can use it yourself in all projects
- Project scope: Installed into
.claude/settings.json, all collaborators in this repository can use it - Local scope: Only in this repository, only you can use it
Just choose the default "User scope" for now.
Expectation: The terminal prompts that the plugin was successfully installed, and may also list what dependencies it automatically installed along with it.
Step 4: Make the plugin take effect and check the commands it brings
/reload-pluginsExpectation: Claude Code reloads and outputs the number of currently loaded plugins, skills, agents, hooks, plugin MCP servers, and LSP servers. Because the skill of commit-commands has a namespace, it provides commands like /commit-commands:commit.
Step 5: Use it—see the plugin's skill in action with your own eyes
First, arbitrarily modify a file in the current directory to create some changes (like creating a new text file), and then type:
/commit-commands:commitExpectation: This skill will help you stage changes, generate a commit message, and create a commit. Seeing it walk through this git commit workflow proves that the plugin is not only installed, but the skill it brings is actually usable—this is the complete experience of "installing a plugin and getting a ready-made workflow for free."
⚠️ If typing
/commit-commands:commitin Step 5 prompts that the command is not found, first confirm whether you ran/reload-pluginsin Step 4; if that still doesn't work, go to the "Errors" tab in/pluginto see the loading error.
By running through these five steps, you have personally verified the complete chain of "add marketplace → install plugin → take effect → use". Installing any plugin in the future will essentially be this same workflow.
💡 One-sentence summary: Add marketplace (
marketplace add) → install plugin (install) → take effect (/reload-plugins) → use namespaced commands—personally running throughcommit-commandsonce is more useful than memorizing ten commands.
07 Want to Package it Yourself? First Understand What the Plugin Directory Looks Like
The preceding content is all about "using other people's plugins," but sooner or later you will wonder, "Can I package my own set of configurations into a plugin?". This section won't teach you how to build one from scratch (that's the volume of a separate article); it will just guide you to recognize what a plugin directory looks like, so you can understand it and know what to expect.
The core of a plugin consists of two parts: an "ID card" file + folders for each component.
The ID card is .claude-plugin/plugin.json, which declares the plugin's name, description, and version:
{
"name": "my-first-plugin",
"description": "A greeting plugin to learn the basics",
"version": "1.0.0"
}Among them, name is the most critical—it is the namespace prefix for the skills. A skill in this plugin will become /my-first-plugin:xxx. version is optional, but only if you set a version number will users receive updates when you update it, so remember to bump the version number every time you release a new version.
The folders for various components are placed in the root directory of the plugin, categorized by type. I've organized the official directory conventions into a table; just follow it and you'll be right:
| What you want to add | Which directory to put it in |
|---|---|
| skill | skills/<name>/SKILL.md |
| subagent | agents/ |
| hook | hooks/hooks.json |
| MCP server | .mcp.json in the root directory |
| LSP server | .lsp.json in the root directory |
The whole plugin looks something like this when laid out:
my-first-plugin/
├── .claude-plugin/
│ └── plugin.json ← ID card, only this goes here
├── skills/
│ └── hello/
│ └── SKILL.md
├── agents/
│ └── reviewer.md
└── hooks/
└── hooks.jsonHere is a pitfall that the official documentation repeatedly emphasizes, and beginners will definitely fall into, which I will highlight for you:
Common error: Do not put
commands/,agents/,skills/, orhooks/inside the.claude-plugin/directory. Onlyplugin.jsonshould be inside.claude-plugin/. All other directories must be at the plugin root level.
To put it plainly: Only one thing is allowed in the .claude-plugin/ folder—plugin.json. All other component folders must be placed under the plugin root directory, at the same level as .claude-plugin/. I fell into this pitfall the first time I packaged one—to save trouble, I conveniently stuffed skills/ into .claude-plugin/. As a result, the plugin clearly loaded successfully, and /reload-plugins reported no errors, but that skill refused to appear no matter what. I checked the name, version, and namespace against plugin.json for a long time, all correct. Finally, I realized the directory was in the wrong place. After moving it out to the same level as plugin.json, it worked immediately.
You may have noticed that this directory structure is almost identical to the .claude/ project structure discussed in Article 13, the agents/ in Article 23, and the .mcp.json in Article 22. This is no coincidence—a plugin is essentially "taking those configurations you scattered around .claude/ and putting them into an independent folder using the same format". That's why the official documentation says scattered configurations can be "converted to a plugin," because the formats are interconnected; just move them over.
If you want to actually get hands-on and test a package you've built, the official documentation provides a shortcut that doesn't require installing a marketplace—use --plugin-dir when starting to directly load a local plugin directory:
claude --plugin-dir ./my-first-pluginThis flag is specifically for development and testing. After modifying the plugin, running /reload-plugins lets you see the effects without going through the whole process of "publishing to a marketplace then installing".
💡 One-sentence summary: Plugin =
.claude-plugin/plugin.json(ID card,namesets namespace) + component folders under the root directory; remember that iron rule—onlyplugin.jsongoes in.claude-plugin/, and all other folders sit in the root directory.
08 Installing Third-Party Plugins: Pass the "Trust Barrier" First
This is the section of the whole article that requires the most caution, and also where beginners are most likely to let their guard down: Plugins are not harmless little tools; they can execute arbitrary code on your machine using your permissions.
Recall the security boundaries discussed in Article 21—the judgment in that article applies equally to plugins, and is even more critical. The official statement is very serious:
Plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine using your user permissions. Only install plugins and add marketplaces from sources you trust.
What does this mean? A plugin may bring hooks (scripts that run automatically), MCP servers (programs that start automatically), and executable files in bin/. When you install and enable it, these things run under your permissions—they can read your files, access the network, and execute commands, with the same privileges as if you typed the commands yourself. Installing a plugin of unknown origin is roughly equivalent to running a stranger's script directly on your computer.
Analogy: Downloading an .exe from an unfamiliar website and double-clicking to run it. You wouldn't just casually download an executable file from a website you've never heard of and double-click it, right? Because once it runs, it can do as much as you can. Installing third-party plugins is of this nature—whether the source is trustworthy is a question you must answer before installing, and you shouldn't just install it directly to save trouble.
So here are three "pre-installation self-checks for third-party plugins" that are worth treating as hard rules:
| Check Item | How to Do It |
|---|---|
| Is the source trustworthy? | Prioritize the official marketplace; for the community marketplace, look at the author and homepage; for unfamiliar personal repositories, don't install if you aren't sure |
| What does it bring? | Before installing, clearly see in the "Will install" section of the /plugin details if it brings hooks / MCP / executable files |
| What is the scope? | If unsure, try "Local scope" first; don't just spread it across all projects with "User scope" right from the start |
A few official designs that can give you a little peace of mind: Plugins in the community marketplace have passed automated validation and security screening, and are pinned to specific commits (authors cannot sneakily swap the content); the official marketplace is curated by Anthropic, which is the most worry-free. But none of these can replace your own judgment—the core is still the phrase "only install from sources you trust".
A safe practice: Install plugins from the official marketplace directly; for the community marketplace, first glance at its homepage to see who it is, what it does, and what permissions it needs before deciding; for private plugins from unfamiliar sources, never touch them unless you can read and understand their code. To be honest, as convenient as plugins are, balancing "convenience" and "security" is always up to you—don't mistake the smoothness of one-click installation for evidence of harmlessness.
💡 One-sentence summary: Plugins can run arbitrary code with your permissions, and installing third-party plugins is equal to running a stranger's script on your machine; three checks before installing—is the source trustworthy, what does it bring, and what is the scope? The official marketplace is the most stable, and it's better not to install from unfamiliar sources.
09 Summary
In this article, we smoothed out Claude Code's "plugins" from concepts to hands-on practice—in essence, it is taking the scattered pieces you learned earlier and packaging them into a box that can be installed/uninstalled, distributed, and updated as a whole.
Let's review the core points strung together:
| What You Need to Do | What to Use | Key Point |
|---|---|---|
| Understand what a plugin is | plugin = packaged box of scattered pieces | Contains skills/subagents/hooks/MCP/LSP; scatter for personal use, package only when sharing |
| Get other people's plugins | Plugin marketplace | Two steps: marketplace add to add marketplace → install to install plugin |
| Recognize marketplaces | Three official marketplaces | Official built-in is most stable, community needs manual adding, demo is for practice |
| Make plugin take effect | /reload-plugins | Installing/stopping halfway relies on it to refresh without restarting |
| See what was installed clearly | /plugin details | "Will install" list + context cost, check before installing |
| Package it yourself | plugin.json + component folders | Only plugin.json goes in .claude-plugin/ |
| Install third-party | Three trust checks | Can run arbitrary code, only install from trusted sources |
You should now be able to: Understand how to choose between plugins and scattered configurations, use the three steps of "add marketplace → install plugin → /reload-plugins" to get ready-made functions from the marketplace, understand the "Will install" list and context cost in the plugin details, recognize what a plugin directory looks like, and be clear that you must pass the trust barrier before installing third-party plugins. This set of capabilities saves you from configuring everything from scratch yourself—off-the-shelf full packages in the marketplace are ready to use.
From Article 18 to this one, you have fully assembled Claude Code's "extension toolbox": CLAUDE.md, MCP, subagents, skills, hooks, and finally used plugins to package and govern them collectively. The tools are now fully equipped.
Next article 25 "Memory System"—The tools are fully equipped, but have you noticed an awkward thing: every time you start a new session, Claude is a blank slate again, and it immediately forgets the preferences you told it last time or the key facts of this project. The next article will talk about how to make Claude "remember" you across sessions—remembering your favorite tech stack, remembering the hard rules of the project, without having to explain them from scratch every time. Think about it: if it could be like an old partner you've worked with for a long time, knowing your habits as soon as it opens its mouth, wouldn't it be much easier?