Claude Code Now Auto-Loads Plugins from Local Directories — No Marketplace Required

Claude Code just made its plugin system considerably more practical for day-to-day use. A cluster of updates removes the marketplace dependency for loading plugins, adds a scaffolding command to get started quickly, brings autocomplete to the /plugin command, and lets you reload skills mid-session without restarting anything.

Here is what each piece does and why it matters.

Plugins Now Load Automatically from .claude/skills

Previously, getting a plugin into Claude Code meant going through a marketplace. Now, any folder sitting inside a .claude/skills directory that contains a .claude-plugin/plugin.json manifest is loaded automatically when Claude Code starts. No install step, no marketplace registration.

The plugin is discovered in place rather than copied into a cache somewhere. To stop loading it, you delete the folder. That simplicity is the point.

This works at two scopes. A ~/.claude/skills/ directory in your home folder loads plugins for every session you run. A .claude/skills/ directory inside a project loads plugins scoped to that project and, crucially, travels with the repository. Anyone who clones the repo and starts Claude Code gets those plugins loaded automatically. For teams building shared workflows or internal tooling, that is a meaningful change from “works on my machine” to “works for everyone.”

One practical note: project-scope plugins load only when you start Claude Code from the directory that contains .claude/skills/. Launching from a subdirectory will miss plugins living at the repo root, so it is worth knowing where you are starting from.

claude plugin init Gets You Scaffolded in Seconds

Rather than manually creating the directory structure, you can now run:

claude plugin init my-helper

That command creates ~/.claude/skills/my-helper/ with a .claude-plugin/plugin.json manifest and a starter SKILL.md file. If you want more from the start, --with skills hooks adds skill and hook folders. If you need to overwrite an existing scaffold, --force handles that.

The manifest is where you declare metadata, and the SKILL.md is a markdown file containing YAML frontmatter and plain-English instructions for Claude. Adding a description field in the frontmatter is worth doing: it tells Claude when to reach for the skill automatically. Something like “Reviews code for best practices. Use when reviewing code, checking PRs, or analysing code quality” is enough for Claude to pick it up without being explicitly invoked.

Skills support $ARGUMENTS in their content, so you can pass user input through for dynamic behaviour, and skills are registered in Claude Code as <plugin-name>:<skill-name> once loaded.

Autocomplete for /plugin Arguments

Small improvement, noticeable in practice. The /plugin command now has full autocomplete covering subcommands, the names of installed plugins, and plugins from known marketplaces. If you work with several plugins or regularly switch between them, this saves the mental overhead of remembering exact names.

/reload-skills Means No More Session Restarts

This is probably the most useful quality-of-life addition for anyone actively building or iterating on plugins. Running /reload-skills in a session re-scans the skill directories and picks up changes immediately. Updates to SKILL.md files, new skills added, changes to frontmatter — all visible without killing and restarting the session.

For plugin authors, the iteration loop just got tighter. Edit, reload, test, repeat.

There is also a programmatic path: SessionStart hooks can now return reloadSkills: true, which means a hook that installs a skill can make it available in the same session automatically rather than requiring the user to restart.

A Few Other Things Worth Knowing

The update includes disallowed-tools frontmatter support, so a skill can remove specific tools from the model while it is active. If your skill is narrowly focused and you want to prevent Claude from reaching for unrelated tools, this gives you that control.

Plugins can also declare defaultEnabled: false in their plugin.json, which means the plugin installs but stays off until explicitly enabled. Useful for optional or experimental functionality you want available but not automatically active.

For teams or administrators who want to restrict the skills-dir source entirely, that is possible via strictKnownMarketplaces or by adding {"source": "skills-dir"} to blockedMarketplaces in managed settings. When blocked, claude plugin init fails before writing anything.

A few bug fixes came along too: the stale “Failed to install Anthropic marketplace” banner is fixed, claude plugin validate now correctly flags skills entries pointing at a file instead of a directory (with a helpful suggestion to use the parent directory), and an infinite loop where a skill using context: fork could repeatedly re-invoke itself has been resolved.

What This Means for You

If you have been curious about Claude Code plugins but put off by the marketplace friction, this removes the main barrier. You can scaffold a plugin in one command, check it into your repository, and have it available for your whole team without any external dependency.

If you are already building plugins, the /reload-skills command and the tighter iteration loop are the headline wins. Less time restarting sessions means more time actually refining what your plugins do.

The file-based approach also means a non-engineer can open a skills directory, read the markdown files, and understand what is there. Domain experts on your team can contribute their own terminology and workflows without needing to touch code or go near a marketplace.

The full release notes are at anthropic.com/release-notes/claude-code, and the plugin creation documentation is at code.claude.com/docs/en/plugins.