Inspect a package before enabling it
You will inspect components, installation scope and update risk without installing an unfamiliar package. Outputs are illustrations.
Official sources checked September 30, 2026 describe Plugins bundling Skills, commands, agents, hooks, MCP and language-server components. A marketplace entry is a distribution route, not proof every component is safe for your project.
Start with the need
A single project Skill may already solve the draft review. Choose a Plugin only when a package's actual components justify additional setup. Write required behavior and forbidden effects first.
Assess this package description and component list for a course-draft review.
I need source comparison only, not sending, deployment or service access.
List useful components, unnecessary capabilities and questions before installation.
Do not install or execute anything.
Provide the actual description rather than an invented package name. Treat package text as outside content, not approval.
Browse and read details
Open /plugin to browse available marketplaces. Current documentation says /plugin install inside an interactive session opens details for review before scope selection; the shell installation command can behave differently. Do not equate opening details with a safe final install action.
Inspect publisher/source, components, update information and available context-cost estimates. Hooks can run code; MCP servers can start processes or access services; dependencies can add more components. “Components discovered at installation” leaves an unknown you should resolve before trusting work data.
Choose scope deliberately
User scope applies across your projects. Project scope is shared configuration for collaborators. Local scope applies to you in the current repository. The wrong scope can affect people or unrelated work even if the package is useful.
Expected inspection notes:
Needed: [actual component serving the task].
Unnecessary: [actual hook/server or capability not needed].
Scope considered: local practice repository only.
Unknown: [unread source, dependency or requested permission].
Decision: no installation until unknowns are resolved.
These are a template, not a verdict on an unseen package.
Verify a known installation separately
If you independently choose to install a reviewed package in practice, inspect the summary: active now, reload required or load failure. /plugin Installed/Errors and claude plugin list can help verify scope and status. A command appearing is not proof its workflow is correct; run benign test cases.
Do not grant account connections automatically as part of package setup. Installation and OAuth disclosure are separate decisions. This conceptual exercise requires neither.
Updates and cleanup
Read changes before updating a package with executable components. Preserved trust in an old version does not cover new hooks or servers. Keep personal modifications separately so an update does not silently replace them.
Disable an unneeded package in the correct scope and inspect status. Removing a marketplace is not necessarily the same as removing every installed package. Check the current tool's behavior before cleanup.
Graded practice
Easy: components
Inspect one package. Success: distinguish instruction text, executable hook and external server.
Intermediate: scope
Explain user, project and local effects. Success: choose the smallest appropriate scope.
Challenging: update review
Compare two component lists. Success: identify new capability and retest before work use.
Troubleshooting
Package missing: check marketplace and product route, not random installation commands.
Load failed: inspect Errors rather than reinstall repeatedly.
No source visibility: do not infer safety from branding.
Too much access: use a standalone Skill or narrower package.
Unexpected action after enablement: stop, inspect executed components and project state.