Plugin Scope And Lifecycle — Claude Code Guide

Scope defines the radius of use

Scope answers “where and for whom is the plugin available?” Permissions answer a different question: “what actions can it perform?” Keep these concepts separate.

Choose the narrowest scope that fits: start experiments locally, use user scope for a stable personal workflow, and use project scope for a shared process only after review.

Plugin lifecycle

1. Find an available marketplace or source.
2. Inspect package contents and capability surface.
3. Install at the intended scope.
4. Confirm that the plugin activated.
5. Test it on a safe task.
6. Review the package again before updating.
7. Disable or uninstall it when it is no longer needed.

/plugin marketplace list
/plugin install <plugin> --scope local
/plugin list
/plugin details <plugin>
/plugin disable <plugin>
/plugin uninstall <plugin>

Namespace and activation

A stable namespace reduces conflicts between skills and commands from different plugins. Installation may not activate a component immediately; refreshing the list, restarting a session, or reopening the project may be required.

review-kit:pr-check
docs-tools:review

Disable, uninstall, and rollback

For a failed experiment, disable it first. If it is no longer needed, uninstall it so inactive packages do not accumulate.

Record a trial log

Plugin: ...
Marketplace/source: ...
Reason for trial: ...
Scope: local
Result: ...
Decision: keep / disable / uninstall
Rollback: ...