Script Skill Mcp Plugin — Claude Code Guide

Choose the simplest automation form

A script, skill, MCP server, and plugin solve different problems. Start with the simplest solution that removes a real recurring need; do not add packaging complexity for its own sake.

Components can combine: a script gathers facts, a skill defines an analysis workflow, MCP adds current external data, and a plugin distributes a verified set.

Form	When to choose it	Scale
Manual action	One-off or not yet proven repeatable	Personal work
Script	Repeatable local mechanics	Developer or repository
Skill	Team needs a consistent Claude workflow and output format	Project or team
MCP	Live external data or operations are necessary	Controlled integration
Plugin	A verified package must be delivered to multiple places	Teams and repositories

Do not confuse component responsibilities

A script provides simple predictable mechanics.
A skill describes inputs, analysis sequence, and response format.
MCP provides a controlled bridge to external data or actions.
A plugin packages a verified workflow for delivery, versioning, and consistent installation.
No packaging form gains authority to make business decisions.

Selection logic

If an action happened once, do it manually.
If one person repeats a local command, create a script.
If several people use the same analysis procedure, create a skill.
If the result is incomplete without live external data, consider MCP.
If a verified workflow is needed in several repositories, evaluate a plugin.

Evolution driven by need

manual action
  -> local script
  -> team skill
  -> MCP for external data
  -> plugin for distribution

Roll out gradually with boundaries

A local helper should not silently become a mandatory gate. An external integration should not receive more access than its scenario requires.

Component	Minimum check
Script	Repeatable local result and clear disable method
Skill	Stable input, output contract, and usage example
MCP	Read-only scenario, narrow data scope, and verified auth path
Plugin	Provenance, versioning, compatibility, docs, and rollback

Ready for team use

README includes start instructions, an example, and expected result.
An owner and supported scope are defined.
Someone other than the author has tested the tool.
The interface and versions are stable.
Logs, disable switch, and rollback path are documented.
The team knows how to react to an incorrect result.

Canonical lesson source · JavaRush

Open JavaRush material