When should I use prompts, skills, MCP, hooks or plugins?

Direct answer

A prompt describes the present task. Project rules supply stable background. A skill preserves a method for a class of tasks. MCP connects an application to external tools and resources. A hook runs a check or action on a specified event. A plugin packages capabilities. These roles are not interchangeable. If AI cannot read the real database, it needs an authorized tool. If it can read the data but judges inconsistently, the missing piece may be a method. Exact support differs by host.\n\nPractical suggestion: fill the current gap first. When the tool already retrieves data, improve the selection criteria. When the method is clear, a longer prompt cannot replace missing read access.

When to use

• You face many plugins and do not know which one to install.
• You want to standardize recurring work but are unsure whether to write instructions or a program.

Step by step

Describe where the failure occurs

Identify whether AI lacks the data, lacks your decision criteria, or knows a rule but skips a check. Do not install a collection of plugins merely to have a complete toolkit.

Preserve a proven method in a skill

Write triggers, inputs, steps, exceptions, output and acceptance for a process you have actually tried. Put long policies, examples and templates in references. Test one task class first; do not make one skill responsible for research, development, marketing and finance.

Connect a tool when real capability is missing

Use an existing connector or suitable MCP server to retrieve a real page, database schema or document. Check the server’s provenance, required permissions and data scope. After connection, run a minimal query; installed does not mean correctly usable.

Use a hook for a repeatable check

Specify the event, input, rejection condition and failure behavior. Deterministic checks can inspect files and test exit statuses. Model-based checks can assist evaluation but can be wrong. A triggered hook does not guarantee a correct conclusion.

Package a combination only after its parts work

Bundle capabilities as a plugin when each has been verified and they will actually be used together. Keep versions and installation provenance, inspect and merge existing settings, and rerun a representative task after upgrades.

Check scope, discovery and triggering separately

Distinguish file existence, client recognition, actual triggering and a satisfactory result. Record version, project or personal scope, dependent scripts and network destinations. Make a recoverable local merge of existing configuration. In Claude Code, personal and project skills have different scopes; consult the installed version’s documentation for skills and custom commands. Other hosts have their own paths and extension fields. For OpenClaw, use its current documented loading sources and precedence rather than assuming a universal three-directory layout.

Improve a skill through versioned experiments

Extract a minimal rule from a real failure: trigger, cause, correct action and counterexample. Keep old samples, add the failure sample, and test intended triggering, non-triggering, missing inputs and tool failures. Replace the version only with evidence of improvement. Split long references by topic and state when to read them. Installing a workflow package does not guarantee zero bugs or justify arbitrary file counts and prohibitions.

Accept the business read after MCP discovery

After interface discovery, use a restricted account to read one known object and compare fields and timestamps with the underlying system. When retrieving documentation through Context7 or a similar tool, specify the library and actual version, confirm critical APIs against official documentation and run a small example. Retrieved documentation does not prove correct code. Before querying a database, check schema, scope, units and denominators; do not reuse demonstration connection strings or overprivileged default accounts.

Test passing, blocking and checker failure

Confirm whether the selected event can block. An event after execution cannot prevent a write that already happened. Exercise a valid case, a prohibited case and checker failure; verify that the mechanism does more than print WARN. Refunds and deletions still need identity and limit checks at the actual execution boundary. Prompt or agent hooks contain model judgment, not mathematical guarantees. Do not create an unbounded loop that launches another review whenever one finishes.

Worked example

Hypothetical exercise: a support reply draft

A mail connector retrieves messages; a support skill defines classification, policy lookup, drafting and handoff; a hook can check required output fields. Sending a real email is a separate authorized action. Successful drafting does not imply permission to send.

Action checklist

• Each component has an identifiable gap to solve.
• The tool read the expected data with appropriate permissions.
• The skill includes examples, exceptions and output criteria.
• A failed check is not presented as success.
• Installation, recognition, triggering and results each have evidence.
• Upgrades are tested on intended, unintended and failing tasks.
• Hook failures, missed matches and checks that execute too late have been exercised.

Reusable templates

Skill draft outline

Task name:
When to use and when not to use:
Required inputs:
Allowed data and tools:
Execution steps:
Exceptions and stopping conditions:
Output format:
Acceptance:
Reference files:
Try one real task. After a failure, revise only the relevant part of the process.

Component installation and acceptance record

Component, repository and pinned version:
Failure it addresses:
Configuration backup or diff before installation:
Scope and final path:
Included scripts, dependencies and network destinations:
Required permissions and credential storage location; never enter secret values:
Evidence that files exist:
Evidence of client recognition:
Actual triggering input and output:
Non-triggering, missing-input and tool-failure results:
Uninstall or rollback procedure:

Turn a failure into a skill improvement

Task and input sample ID:
Previous rule version and actual error:
Cause: missing data / missing tool / incorrect method / skipped check
Scope of the new rule:
Counterexample where it does not apply:
Smallest correction:
Old-sample and new-failure regression results:
False triggers and maintenance cost:
Adopt or withdraw decision and version:

Pitfalls

• MCP is a connection mechanism, not a guarantee of external accuracy, and tools can exist without MCP.
• A hook is not guaranteed to be correct, especially when it relies on model judgment.
• More components increase context, configuration and maintenance burden.
• Skills describe methods; CLI, API and MCP describe interfaces or connections; computer use describes interaction. They cannot be automatically ranked on a single safety pyramid.
• Portability does not make directories, events, dependencies, credentials and permissions interchangeable. A persona definition is not a security policy.

Related guides

• What should project rules such as AGENTS.md or CLAUDE.md contain?
• Which work is worth automating with AI?
• How should I limit an AI agent’s permissions?
• How do I build a customer-support workflow that closes the loop?

Official references

• Model Context Protocol: architecture. Documentation review recorded: 2026-10-18; confirm the applicable version before use.
• Claude Code: hooks. Documentation review recorded: 2026-10-18; confirm the applicable version before use.
• Claude Code: skills. Documentation review recorded: 2026-10-18; confirm the applicable version before use.
• OpenClaw: skills. Documentation review recorded: 2026-10-18; confirm the applicable version before use.
• Context7: official repository. Documentation review recorded: 2026-10-18; confirm the applicable version before use.