Claude Code Cheat Sheet
Six extension mechanisms. One reference page. Know which tool to reach for.
Quick Reference
All five mechanisms at a glance.
| Mechanism | What It Does | When to Use | Invocation |
|---|---|---|---|
| Skills | Reusable prompt templates with tool restrictions and $ARGUMENTS interpolation | Repeatable workflows your team runs often (deploy, review, scaffold) | /skill-name or auto-matched by description |
| Custom Agents | Specialized sub-agents with constrained tool access and custom instructions | Parallel workstreams that need isolated context (test-runner, docs-writer) | Spawned via the Task tool inside a session |
| Hooks | Shell commands triggered by lifecycle events (pre/post tool call, notification, etc.) | Guardrails, auto-formatting, logging, blocking destructive commands | Automatic — fires on matching events |
| MCP Servers | External tool servers that give Claude new capabilities (DB access, APIs, browser) | Connecting Claude to systems it can't reach natively (Jira, Postgres, Figma) | Tools appear automatically once server is configured |
| Plugins | Installable bundles that package skills, agents, hooks, and MCP config into one unit | Adopting a pre-built workflow (TDD pipeline, memory, codebase analysis) or distributing your own | /plugin install or /plugin marketplace |
| Slash Commands (Legacy) | Predefined prompts invoked with /command syntax — now migrated to Skills | N/A — use Skills instead. Existing slash commands still work for backwards compat. | /command-name (deprecated in favor of Skills) |
Decision Guide
Start from what you need, find the right mechanism.
I need a repeatable workflow my whole team can trigger
→ Skills
Drop a markdown file in .claude/skills/ — anyone on the team gets it via /skill-name.
I need to run multiple AI tasks in parallel with different permissions
→ Custom Agents
Define agents in .claude/agents/ — each gets its own tool allowlist and system prompt.
I need to automatically block or modify tool calls
→ Hooks
Add a hook in .claude/settings.json — it runs your shell command before/after tool execution.
I need Claude to talk to an external system (database, API, browser)
→ MCP Servers
Add the server to .mcp.json — Claude discovers its tools automatically.
I need to enforce coding standards on every commit
→ Hooks + Skills
Use a pre-commit hook for enforcement, plus a /lint skill for on-demand fixes.
I need to codify tribal knowledge so new devs ramp up faster
→ Skills + CLAUDE.md
Encode patterns as skills, document conventions in CLAUDE.md. AI becomes the onboarding buddy.
I need a complete, pre-built workflow someone else maintains
→ Plugins
Install a community plugin that bundles skills + hooks + agents into a tested workflow. One command, everything wired.
I need to share my team's Claude Code setup across repos
→ Plugins
Package your skills, agents, hooks, and MCP config as a plugin. Versioned, documented, installable with one command.
Skills
Reusable prompt templates that your team can invoke by name or let Claude auto-match by description.
Config: .claude/skills/*.md
Frontmatter
name— Human-readable skill namedescription— When to use this skill (used for auto-matching)allowed_tools— List of tools the skill can use (e.g., Bash, Read, Write)user_invocable— true/false — whether users can trigger via /name
--- name: deploy description: Deploy the current branch to staging or production allowed_tools: - Bash - Read user_invocable: true --- Deploy the app using the following steps: 1. Run tests: `npm test` 2. Build: `npm run build` 3. Deploy to the environment specified in $ARGUMENTS (default: staging) 4. Verify the deployment health check passes 5. Report the deployed URL back to the user
Gotchas
- $ARGUMENTS is the raw string after the /command — parse it yourself if you need flags.
- Skills are project-scoped (.claude/skills/) not global. Commit them to your repo.
- allowed_tools restricts what Claude can do INSIDE the skill — use it to prevent unintended side effects.
- Auto-matching uses the description field. Be specific or you'll get false triggers.
Custom Agents
Specialized sub-agents that run with their own system prompt and tool restrictions. Ideal for parallel workstreams.
Config: .claude/agents/*.md
Frontmatter
name— Agent identifier (used in Task tool calls)description— What this agent specializes inallowed_tools— Whitelist of tools (empty = all tools)model— Optional model override (sonnet, opus, haiku)
--- name: test-runner description: Run tests and report failures with suggested fixes allowed_tools: - Bash - Read - Grep - Glob model: sonnet --- You are a test-running specialist. When invoked: 1. Identify the test framework in use (check package.json, pytest.ini, etc.) 2. Run the full test suite 3. For any failures, read the failing test and source code 4. Report: which tests failed, why, and a suggested fix 5. Never modify source code — only report findings
Gotchas
- Agents run as sub-processes — they don't share conversation context with the parent.
- Use the model field to run cheaper agents on Haiku for cost savings.
- Agents can't spawn other agents (no nested Task calls).
- Keep agent prompts focused. A 'do everything' agent defeats the purpose.
Hooks
Shell commands that fire automatically on lifecycle events. Use them for guardrails, formatting, logging, and notifications.
Config: .claude/settings.json → hooks
Lifecycle Events
| Event | Description | Blocking? |
|---|---|---|
PreToolUse | Fires before a tool executes. Return non-zero to block it. | Yes |
PostToolUse | Fires after a tool completes. Access the result via stdin. | No |
Notification | Fires when Claude sends a notification (e.g., task complete). | No |
Stop | Fires when the agent turn ends. | No |
Examples
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": "bash -c 'read input; echo \"$input\" | jq -r .tool_input.command | grep -qE \"git (push --force|reset --hard|clean -f)\" && exit 1 || exit 0'"
}
]
}
}
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"command": "bash -c 'read input; FILE=$(echo \"$input\" | jq -r .tool_input.file_path); npx prettier --write \"$FILE\" 2>/dev/null || true'"
}
]
}
}
{
"hooks": {
"Notification": [
{
"command": "bash -c 'read input; MSG=$(echo \"$input\" | jq -r .message); osascript -e \"display notification \\\"$MSG\\\" with title \\\"Claude Code\\\"\"'"
}
]
}
}
Gotchas
- PreToolUse hooks can block tool execution — test them carefully or you'll break Claude's workflow.
- Hook commands receive JSON on stdin with tool_input and (for post) tool_result.
- Hooks run in your shell environment. Keep them fast — slow hooks slow down every tool call.
- Use the matcher field to scope hooks to specific tools. Without it, the hook fires on ALL tools.
MCP Servers
Model Context Protocol servers expose external tools to Claude. Once configured, their tools appear automatically — no prompt engineering needed.
Config: .mcp.json (project root) or ~/.claude/mcp.json (global)
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"DATABASE_URL": "postgresql://localhost:5432/myapp"
}
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
Popular MCP Servers
| Server | Package | What It Does |
|---|---|---|
| Postgres | @modelcontextprotocol/server-postgres | Query databases, inspect schemas, run migrations |
| GitHub | @modelcontextprotocol/server-github | Create issues, manage PRs, search repos |
| Filesystem | @modelcontextprotocol/server-filesystem | Sandboxed file access outside the project directory |
| Puppeteer | @anthropic/mcp-server-puppeteer | Browser automation, screenshots, form filling |
| Slack | @anthropic/mcp-server-slack | Read channels, post messages, search history |
Gotchas
- MCP servers run as long-lived processes. A crashing server = missing tools until restart.
- Use env vars for secrets — never hardcode tokens in .mcp.json.
- Project-level .mcp.json overrides global config for the same server name.
- Run 'claude mcp list' to see which servers are active and which tools they provide.
Plugins
Plugins are installable packages that bundle skills, agents, hooks, and MCP config into a single unit. Instead of manually wiring each extension mechanism, you install one plugin and everything connects. Think of them as the distribution layer on top of the five mechanisms above.
Config: Managed via /plugin commands
What a plugin contains
A plugin is a Git repository with any combination of skills, agents, hooks, and MCP server config. One install adds all of them to your project. Authors maintain, version, and document them like any open source package.
Marketplaces
Plugins are organized into marketplaces (curated registries of plugins). Add a marketplace, then browse and install plugins from it.
Build vs. install
You can build your own plugins to distribute your team's setup across repos, or install community plugins for common workflows like TDD pipelines, code analysis, or memory systems.
Commands
| Command | What It Does |
|---|---|
/plugin | Open the plugin manager (browse, install, manage, update) |
/plugin marketplace add <owner/repo> | Add a marketplace (curated plugin registry) |
/plugin install <name>@<marketplace> | Install a specific plugin from a marketplace |
Gotchas
- Plugins inject skills, hooks, and agents into your project. Review what a plugin adds before installing, especially hooks that run shell commands.
- Community plugins reflect the author's workflow and opinions. A plugin that enforces strict TDD might conflict with your team's process.
- More plugins means more context for Claude to process. Senior engineers in the community report that a focused, vanilla setup often outperforms a stack of plugins.
- The plugin ecosystem is young and changing fast. Pin versions and test updates before rolling them out to your whole team.
Why Your Org Should Build Custom Plugins
The ROI of investing in Claude Code customization.
Consistency at Scale
When 20 developers prompt Claude differently, you get 20 different patterns. Skills and agents encode your team's best practices into reusable templates. Every engineer gets the same high-quality output — the senior architect's approach, automated.
Guardrails That Actually Work
Hooks let you enforce rules at the tool level, not the honor system. Block force-pushes, require test runs before commits, auto-format code — all without relying on developers remembering to follow the process.
Faster Onboarding
New developers run /setup and get a working environment. They run /deploy and it just works. The tribal knowledge that used to live in a senior engineer's head is now executable. Onboarding drops from weeks to days.
Tribal Knowledge Codification
Every organization has unwritten rules: 'always use the v2 API for payments,' 'never query the users table without a tenant filter.' Skills and CLAUDE.md turn these into enforceable standards that survive employee turnover.
Compound Returns
Each plugin you build saves time on every future session. A /review skill that takes an hour to write saves 10 minutes per PR — across 50 PRs/week, that's 400+ hours saved per year. The investment compounds.
✅
Ready to Go Deeper?
This cheat sheet covers the mechanics. For the full strategy — how to roll out AI coding across your team, calculate ROI, and avoid the common pitfalls — read the guide.