Skip to main content
guidesSource-backed

Choose the Right Claude Extension Surface

A practical decision guide for choosing between Claude Code subagents, skills, slash commands, hooks, settings, and MCP servers. Pick the smallest extension surface that matches the workflow, risk, and sharing model.

by MkDev11·added 2026-06-04·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Safety notes
Choose the smallest surface that solves the workflow; avoid giving a workflow live tools or lifecycle automation when a prompt template is enough., Review hooks and MCP servers more carefully than static prompts because they can interact with local commands, files, tools, or external services., Keep project-shared extensions documented so teammates know what runs automatically and what Claude can access.
Privacy notes
Skills, slash commands, settings, hooks, subagents, and MCP configuration can contain project names, file paths, prompts, tool descriptions, and workflow policy., MCP tools and hooks may process local files, command output, API responses, logs, or other repository context depending on configuration., Keep personal credentials out of shared project extensions and prefer environment-specific configuration for sensitive access.
Author
MkDev11
Submitted by
MkDev11
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

4 prerequisites to line up before setup.

0/4 ready
Permissions & scopes1General3

Safety & privacy surface

Safety & privacy surface

3 safety and 3 privacy notes across 5 risk areas. Review closely: credentials & tokens, third-party handling.

5 areas
  • SafetyGeneralChoose the smallest surface that solves the workflow; avoid giving a workflow live tools or lifecycle automation when a prompt template is enough.
  • SafetyThird-party handlingReview hooks and MCP servers more carefully than static prompts because they can interact with local commands, files, tools, or external services.
  • SafetyExecution & processesKeep project-shared extensions documented so teammates know what runs automatically and what Claude can access.
  • PrivacyLocal filesSkills, slash commands, settings, hooks, subagents, and MCP configuration can contain project names, file paths, prompts, tool descriptions, and workflow policy.
  • PrivacyLocal filesMCP tools and hooks may process local files, command output, API responses, logs, or other repository context depending on configuration.
  • PrivacyCredentials & tokensKeep personal credentials out of shared project extensions and prefer environment-specific configuration for sensitive access.

Safety notes

  • Choose the smallest surface that solves the workflow; avoid giving a workflow live tools or lifecycle automation when a prompt template is enough.
  • Review hooks and MCP servers more carefully than static prompts because they can interact with local commands, files, tools, or external services.
  • Keep project-shared extensions documented so teammates know what runs automatically and what Claude can access.

Privacy notes

  • Skills, slash commands, settings, hooks, subagents, and MCP configuration can contain project names, file paths, prompts, tool descriptions, and workflow policy.
  • MCP tools and hooks may process local files, command output, API responses, logs, or other repository context depending on configuration.
  • Keep personal credentials out of shared project extensions and prefer environment-specific configuration for sensitive access.

Prerequisites

  • A Claude Code workflow you want to make repeatable, safer, or more capable.
  • Agreement on whether the extension is personal, project-level, team-shared, or environment-specific.
  • A list of data, tools, commands, or external systems the workflow may touch.
  • Permission to add project files or configure Claude Code for the target repository.

Schema details

Install type
copy
Reading time
8 min
Difficulty score
54
Troubleshooting
Yes
Breaking changes
No
Full copyable content
## TL;DR

Use the smallest Claude extension surface that fits the job:

- **Skill**: reusable expertise, standards, or process knowledge.
- **Slash command**: a user-triggered workflow shortcut.
- **Hook**: deterministic automation around a Claude Code lifecycle event.
- **Subagent**: delegated specialist work with its own focus and context.
- **MCP server**: live tools, resources, or external systems.
- **Settings**: project or user policy that should apply consistently.

When two surfaces could work, choose the one with less runtime authority. A
static skill or slash command is usually easier to review than a hook or MCP
server because it does not add live access by itself.

## Prerequisites & Requirements

- [ ] {"task": "Workflow is named", "description": "You can describe the repeated task in one sentence"}
- [ ] {"task": "Sharing scope is known", "description": "The extension is personal, project-local, team-shared, or organization-managed"}
- [ ] {"task": "Access needs are mapped", "description": "You know whether the workflow needs prompts only, repository files, commands, or external systems"}
- [ ] {"task": "Risk is understood", "description": "You know whether the workflow can read data, write files, call tools, or run automatically"}

## Core Concepts Explained

### Skills package reusable expertise

Choose a skill when Claude needs durable guidance: domain conventions, review
criteria, migration steps, testing heuristics, or a playbook that should travel
between sessions. Skills are a good fit when the main value is knowledge and
instructions rather than a live integration.

### Slash commands package repeatable prompts

Choose a slash command when a human should intentionally start a workflow with a
short command. They are useful for recurring tasks such as review checklists,
release notes, triage prompts, migration planning, or issue analysis.

### Hooks package deterministic automation

Choose a hook when something should happen at a lifecycle point without a user
typing a prompt each time. Hooks are best for narrow, predictable automation:
notifications, formatting checks, logging, guardrails, or context reminders.

### Subagents package delegated specialist work

Choose a subagent when Claude should hand a task to a focused specialist. A
subagent can carry a narrower role, review lens, or domain focus than the main
conversation. Use this when separation of attention matters.

### MCP packages live capability

Choose MCP when Claude needs to interact with tools, resources, APIs, databases,
files, or services through a protocol boundary. MCP is the right surface for
live data and actions, but it also deserves the most access review.

### Settings package policy

Choose settings for behavior that should apply consistently across the user or
project environment: allowed tools, model preferences, permissions, or team
defaults. Settings are not a workflow by themselves; they shape the environment
where workflows run.

## Step-by-Step Decision Guide

1. **Start with the output.** If the workflow produces advice, a checklist, a
   review, or a plan, start with a skill or slash command. If it must interact
   with live systems, consider MCP.

2. **Decide who starts it.** If a human should opt in each time, use a slash
   command. If the behavior should apply automatically at a lifecycle point,
   use a hook.

3. **Decide whether expertise should travel.** If the workflow is mostly
   reusable know-how, package it as a skill. A skill can include process,
   examples, rubrics, and references without creating a live integration.

4. **Decide whether work needs delegation.** If the task benefits from a
   specialist role or separate focus, use a subagent. This is useful for code
   review, test planning, security triage, documentation review, or domain
   analysis.

5. **Decide whether Claude needs live capabilities.** If Claude must read a
   resource, call an API, query a database, inspect an issue tracker, or invoke
   a tool, use MCP and review the exposed tools/resources.

6. **Put policy in settings.** If the question is "what should Claude be allowed
   to do here?" instead of "what workflow should Claude run?", use settings.

7. **Combine surfaces only when needed.** A slash command can call on a skill; a
   subagent can use MCP tools; a hook can remind Claude about policy. Keep each
   layer small enough that a teammate can review it.

## Decision Matrix

| Need | Best surface | Why |
| --- | --- | --- |
| Reusable domain guidance | Skill | Durable instructions and examples without live access |
| Repeatable manual workflow | Slash command | Human-triggered and easy to discover |
| Automatic lifecycle behavior | Hook | Runs at a defined event instead of relying on memory |
| Focused delegated analysis | Subagent | Keeps a specialist role and context separate |
| Live tools or external data | MCP | Standard surface for tools/resources/services |
| Consistent project policy | Settings | Applies defaults and permission boundaries |

## Review Checklist

- [ ] {"task": "Smallest surface", "description": "The extension does not add automation or live access unless needed"}
- [ ] {"task": "Clear owner", "description": "A person or team owns updates and review"}
- [ ] {"task": "Sharing scope", "description": "Personal, project, team, or organization scope is documented"}
- [ ] {"task": "Access review", "description": "Hooks and MCP tools are reviewed for files, commands, services, and side effects"}
- [ ] {"task": "Discoverability", "description": "Teammates can find and understand the extension"}
- [ ] {"task": "Rollback path", "description": "The extension can be disabled, removed, or replaced safely"}

## Troubleshooting

- **The workflow is becoming too broad**: split it into a skill for reusable
  knowledge plus a slash command for the entry point.
- **A hook is doing too much**: move judgment-heavy work into a command or skill
  and keep the hook deterministic.
- **An MCP server is used only for static text**: replace it with a skill or
  command unless live resources are actually required.
- **Subagents overlap heavily**: merge roles or define sharper handoff criteria.
- **Settings hide project behavior**: document the policy in the repository so
  teammates understand what applies automatically.

## Duplicate Check

This guide is a decision framework for choosing between Claude Code extension
surfaces. Existing entries cover individual commands, hooks, agents, skills, and
MCP servers, but they do not provide a source-backed comparison that helps teams
choose the smallest appropriate surface for a workflow.

## References

- Claude Code subagents - https://code.claude.com/docs/en/sub-agents
- Claude Code skills - https://code.claude.com/docs/en/skills
- Claude Code slash commands - https://code.claude.com/docs/en/slash-commands
- Claude Code hooks - https://code.claude.com/docs/en/hooks
- Claude Code MCP - https://code.claude.com/docs/en/mcp
- Claude Code settings - https://code.claude.com/docs/en/settings

About this resource

TL;DR

Use the smallest Claude extension surface that fits the job:

  • Skill: reusable expertise, standards, or process knowledge.
  • Slash command: a user-triggered workflow shortcut.
  • Hook: deterministic automation around a Claude Code lifecycle event.
  • Subagent: delegated specialist work with its own focus and context.
  • MCP server: live tools, resources, or external systems.
  • Settings: project or user policy that should apply consistently.

When two surfaces could work, choose the one with less runtime authority. A static skill or slash command is usually easier to review than a hook or MCP server because it does not add live access by itself.

Prerequisites & Requirements

  • {"task": "Workflow is named", "description": "You can describe the repeated task in one sentence"}
  • {"task": "Sharing scope is known", "description": "The extension is personal, project-local, team-shared, or organization-managed"}
  • {"task": "Access needs are mapped", "description": "You know whether the workflow needs prompts only, repository files, commands, or external systems"}
  • {"task": "Risk is understood", "description": "You know whether the workflow can read data, write files, call tools, or run automatically"}

Core Concepts Explained

Skills package reusable expertise

Choose a skill when Claude needs durable guidance: domain conventions, review criteria, migration steps, testing heuristics, or a playbook that should travel between sessions. Skills are a good fit when the main value is knowledge and instructions rather than a live integration.

Slash commands package repeatable prompts

Choose a slash command when a human should intentionally start a workflow with a short command. They are useful for recurring tasks such as review checklists, release notes, triage prompts, migration planning, or issue analysis.

Hooks package deterministic automation

Choose a hook when something should happen at a lifecycle point without a user typing a prompt each time. Hooks are best for narrow, predictable automation: notifications, formatting checks, logging, guardrails, or context reminders.

Subagents package delegated specialist work

Choose a subagent when Claude should hand a task to a focused specialist. A subagent can carry a narrower role, review lens, or domain focus than the main conversation. Use this when separation of attention matters.

MCP packages live capability

Choose MCP when Claude needs to interact with tools, resources, APIs, databases, files, or services through a protocol boundary. MCP is the right surface for live data and actions, but it also deserves the most access review.

Settings package policy

Choose settings for behavior that should apply consistently across the user or project environment: allowed tools, model preferences, permissions, or team defaults. Settings are not a workflow by themselves; they shape the environment where workflows run.

Step-by-Step Decision Guide

  1. Start with the output. If the workflow produces advice, a checklist, a review, or a plan, start with a skill or slash command. If it must interact with live systems, consider MCP.

  2. Decide who starts it. If a human should opt in each time, use a slash command. If the behavior should apply automatically at a lifecycle point, use a hook.

  3. Decide whether expertise should travel. If the workflow is mostly reusable know-how, package it as a skill. A skill can include process, examples, rubrics, and references without creating a live integration.

  4. Decide whether work needs delegation. If the task benefits from a specialist role or separate focus, use a subagent. This is useful for code review, test planning, security triage, documentation review, or domain analysis.

  5. Decide whether Claude needs live capabilities. If Claude must read a resource, call an API, query a database, inspect an issue tracker, or invoke a tool, use MCP and review the exposed tools/resources.

  6. Put policy in settings. If the question is "what should Claude be allowed to do here?" instead of "what workflow should Claude run?", use settings.

  7. Combine surfaces only when needed. A slash command can call on a skill; a subagent can use MCP tools; a hook can remind Claude about policy. Keep each layer small enough that a teammate can review it.

Decision Matrix

Need Best surface Why
Reusable domain guidance Skill Durable instructions and examples without live access
Repeatable manual workflow Slash command Human-triggered and easy to discover
Automatic lifecycle behavior Hook Runs at a defined event instead of relying on memory
Focused delegated analysis Subagent Keeps a specialist role and context separate
Live tools or external data MCP Standard surface for tools/resources/services
Consistent project policy Settings Applies defaults and permission boundaries

Review Checklist

  • {"task": "Smallest surface", "description": "The extension does not add automation or live access unless needed"}
  • {"task": "Clear owner", "description": "A person or team owns updates and review"}
  • {"task": "Sharing scope", "description": "Personal, project, team, or organization scope is documented"}
  • {"task": "Access review", "description": "Hooks and MCP tools are reviewed for files, commands, services, and side effects"}
  • {"task": "Discoverability", "description": "Teammates can find and understand the extension"}
  • {"task": "Rollback path", "description": "The extension can be disabled, removed, or replaced safely"}

Troubleshooting

  • The workflow is becoming too broad: split it into a skill for reusable knowledge plus a slash command for the entry point.
  • A hook is doing too much: move judgment-heavy work into a command or skill and keep the hook deterministic.
  • An MCP server is used only for static text: replace it with a skill or command unless live resources are actually required.
  • Subagents overlap heavily: merge roles or define sharper handoff criteria.
  • Settings hide project behavior: document the policy in the repository so teammates understand what applies automatically.

Duplicate Check

This guide is a decision framework for choosing between Claude Code extension surfaces. Existing entries cover individual commands, hooks, agents, skills, and MCP servers, but they do not provide a source-backed comparison that helps teams choose the smallest appropriate surface for a workflow.

References

Source citations

Add this badge to your README

Show that Choose the Right Claude Extension Surface is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/guides/choose-claude-extension-surface.svg)](https://heyclau.de/entry/guides/choose-claude-extension-surface)

How it compares

Choose the Right Claude Extension Surface side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field

A practical decision guide for choosing between Claude Code subagents, skills, slash commands, hooks, settings, and MCP servers. Pick the smallest extension surface that matches the workflow, risk, and sharing model.

Open dossier

A practical guide for keeping Claude Code sessions focused during long coding work with scoped prompts, checkpoints, durable memory boundaries, source refreshes, and privacy-safe handoffs.

Open dossier

A practical migration guide for moving Cursor-style rules, prompts, MCP configuration, and team workflows into Claude Code memory, slash commands, MCP, settings, and reviewable project conventions.

Open dossier

A source-backed safety checklist for introducing Claude Code hooks with scoped events, minimal authority, reviewable commands, clear ownership, and a rollback path.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
SubmitterMkDev11MkDev11MkDev11MkDev11
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandCursor logoCursor
Categoryguidesguidesguidesguides
SourceSource-backedSource-backedSource-backedSource-backed
AuthorMkDev11MkDev11MkDev11MkDev11
Added2026-06-042026-06-042026-06-042026-06-04
Platforms
Harness
Source repo
Safety notesChoose the smallest surface that solves the workflow; avoid giving a workflow live tools or lifecycle automation when a prompt template is enough. Review hooks and MCP servers more carefully than static prompts because they can interact with local commands, files, tools, or external services. Keep project-shared extensions documented so teammates know what runs automatically and what Claude can access.Do not paste credentials, production secrets, private customer records, or unrelated proprietary files into prompts just to "fill context." Treat long-session conclusions as provisional when the repository, dependencies, docs, or issue state may have changed. Keep implementation authority separate from analysis: ask for review before applying broad file edits, running risky commands, or changing public project state.Do not copy old Cursor rules or MCP configuration wholesale. Review each item for stale instructions, broad tool access, embedded secrets, and editor-specific assumptions. Start migrated Claude Code workflows with read-only or advisory behavior before allowing tools to write files, run commands, or call external systems. Keep human review around public comments, issue actions, commits, and other repository state changes until the migrated workflow is proven stable.Treat hook commands like project automation code: review them before enabling, keep them small, and avoid hidden side effects. Start with read-only or notification-style hooks before adding hooks that write files, block tools, run package scripts, or call external services. Never store credentials in hook configuration; use environment-specific secret handling and avoid printing secrets to logs.
Privacy notesSkills, slash commands, settings, hooks, subagents, and MCP configuration can contain project names, file paths, prompts, tool descriptions, and workflow policy. MCP tools and hooks may process local files, command output, API responses, logs, or other repository context depending on configuration. Keep personal credentials out of shared project extensions and prefer environment-specific configuration for sensitive access.Long coding sessions can accumulate source code, file paths, stack traces, logs, issue details, usernames, and internal decisions. Durable memory and project instructions can persist sensitive details longer than an ordinary prompt, so store only stable, non-secret facts there. Handoff summaries should mention decisions and next steps without copying full private logs, tokens, customer reports, or unnecessary code excerpts.Cursor rules, memories, prompts, and MCP files can contain internal architecture details, file paths, private package names, issue links, and credentials-adjacent configuration. Claude Code memory, slash commands, and MCP configuration may preserve or replay those details across sessions if they are copied without filtering. Remove secrets, customer data, private incident details, and local-only paths before putting migration output in shared project files.Hook input and output may include prompts, file paths, tool names, command output, error messages, repository context, and user-provided text. Logs created by hooks can retain sensitive project names, local paths, customer reports, or excerpts from code and command output. Network-capable hooks can expose local metadata outside the workspace, so document destinations and get team approval first.
Prerequisites
  • A Claude Code workflow you want to make repeatable, safer, or more capable.
  • Agreement on whether the extension is personal, project-level, team-shared, or environment-specific.
  • A list of data, tools, commands, or external systems the workflow may touch.
  • Permission to add project files or configure Claude Code for the target repository.
  • A Claude Code project or repository with enough scope that work may span several prompts or sessions.
  • Agreement on what belongs in durable memory, project instructions, slash commands, or temporary conversation context.
  • A habit of validating source URLs, test results, and repository state before relying on old assumptions.
  • A place to record handoff summaries, decisions, and unresolved risks without storing secrets.
  • A repository that already uses Cursor rules, prompt templates, MCP configuration, or editor-specific AI workflow conventions.
  • Claude Code access in the target development environment.
  • A list of team conventions that should remain durable after migration.
  • Permission to review and move any MCP credentials, local tool access, or project instructions.
  • A trusted Claude Code workspace where hook behavior is allowed by project or user policy.
  • A specific lifecycle event you want to automate, such as notification, pre-tool review, post-tool follow-up, or session cleanup.
  • A reviewed command or script owned by the project, with a documented rollback path.
  • Agreement on which data the hook may read, write, log, or send outside the machine.
Install
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.