Claude Mods: Every Way to Customize Claude Code (2026 Guide)

Short answer: "Claude mods" are customizations that change how Claude Code works. There is no single mod format. Claude Code has a handful of official extension points – CLAUDE.md project memory, slash commands, skills, subagents, hooks, MCP servers, the status line, output styles and plugins – and each one is just files in your project's .claude/ folder or your user settings. Pick the lightest one that solves your problem, keep it in version control, and read any community mod before you install it.

If you already know what you want, describe it in the free Claude mods generator and it writes a starter file for the right extension point. The rest of this guide explains the options so you can judge the result.

The eight kinds of Claude Code mods

1. CLAUDE.md – project rules

CLAUDE.md is a Markdown file Claude Code reads at the start of a session. Put the things you would tell a new teammate on day one: how to run the tests, which package manager to use, code style rules, folders to leave alone. You can keep one in the repository root (shared with the team) and a personal one in your home folder. It is the simplest and most underused mod: many "Claude keeps doing X" complaints disappear once X is written here.

2. Slash commands – prompts you reuse

A custom slash command is a Markdown file in .claude/commands/. The file name becomes the command, so review.md runs as /review. The file holds the prompt, and it can take arguments. Good candidates: a pull-request review checklist, "write a changelog entry for the last commit", "explain this error and propose a fix".

3. Skills – procedures Claude picks up by itself

A skill is a folder with a SKILL.md file (plus any scripts or reference files it needs) in .claude/skills/. The front matter has a name and a description; when your request matches the description, Claude loads the skill and follows it. The difference from a slash command: you don't have to remember to call it. Skills suit longer procedures such as "how we write database migrations" or "how to build a release".

4. Subagents – specialists with their own context

Subagents are defined in .claude/agents/ as Markdown files with YAML front matter: a name, a description, which tools they may use and their own instructions. Claude can hand a task to them, and they work in a separate context window, which keeps your main conversation clean. Typical examples are a code reviewer with read-only tools, a test runner, or a researcher that searches the codebase and reports back.

5. Hooks – things that must always happen

Hooks are shell commands configured in settings.json that run automatically on events in a Claude Code session – for example before a tool runs (PreToolUse), after it runs (PostToolUse), when you submit a prompt, or when Claude stops. Unlike instructions, hooks are deterministic: they run every time, whether or not the model "remembers". That makes them the right tool for formatting after each edit, blocking dangerous commands, logging, or sending a notification when a long task finishes. Check the Claude Code hooks reference for the current list of events and the exact JSON shape, because they have grown over time.

6. MCP servers – outside tools and data

The Model Context Protocol (MCP) lets Claude Code talk to other systems: a database, an issue tracker, a browser, your company's docs. You add a server once and its tools appear in Claude Code. Use MCP when the information Claude needs is not in your files.

7. Status line and output styles – the look and voice

The status line at the bottom of Claude Code can run your own script, so you can show the model, the git branch, the current directory or how full the context is. Output styles change how Claude responds – more explanatory for learning, terser for experienced users.

8. Plugins – mods in a bundle

A plugin packages commands, agents, skills, hooks and MCP servers so you can install them together. In Claude Code you run /plugin to add a marketplace (often a GitHub repository) and install plugins from it. Plugins are how teams share a standard setup, and how most "Claude mods" collections are distributed today.

Which one should you use?

Work from light to heavy:

1. A rule Claude should follow → write it in CLAUDE.md.
2. A prompt you type again and again → slash command.
3. A procedure Claude should apply on its own when it fits → skill.
4. A job that needs its own context or restricted tools → subagent.
5. Something that must happen every single time → hook.
6. Data or actions outside your repository → MCP server.
7. A set of the above for your whole team → plugin.

A common mistake is building a plugin or an MCP server for what one line in CLAUDE.md would fix. Another is writing "always run the linter" as an instruction when a PostToolUse hook would guarantee it.

Popular Claude Code mod ideas

• Auto-format on edit: a PostToolUse hook that runs Prettier, Black or your linter on the file Claude just changed.
• Guard rails: a PreToolUse hook that refuses rm -rf, force pushes, or edits to .env files.
• "Done" notification: a hook that pings your desktop or phone when Claude stops, so you can leave long tasks running.
• /review: a slash command with your team's review checklist.
• Release skill: a skill that knows your version bump, changelog and tag steps.
• Read-only reviewer subagent: allowed to read and search, not to edit.
• Rich status line: model, branch, uncommitted changes and context usage at a glance.

Type any of these into the generator to get a starter you can adapt.

How to install a community mod safely

Mods run with your permissions. A hook executes shell commands without asking, and a plugin or MCP server can read files and reach the network. Before you install something from a repository or marketplace:

• Read the files. Hooks and scripts are short; look at what they actually run.
• Check where data goes. Any network call in a hook or server should have an obvious reason.
• Prefer maintained projects with recent commits and open issues being answered.
• Test in a throwaway project without secrets or production credentials.
• Keep project mods in git so every change is visible and easy to undo.
• Don't switch off permission prompts globally to make a mod "work"; allow only the specific commands it needs.

FAQ

What are Claude mods? An informal name for Claude Code customizations: CLAUDE.md rules, slash commands, skills, subagents, hooks, MCP servers, status lines, output styles and plugins.

Where are Claude Code mods stored? Project-level ones in the .claude/ folder of your repository (plus CLAUDE.md in the root); personal ones in the .claude/ folder in your home directory.

Do I need to code to make a Claude mod? No for CLAUDE.md, slash commands, skills and subagents – they are Markdown. Hooks and status lines need a small shell command or script.

What's the difference between a skill and a plugin? A skill is one procedure. A plugin is a package that can contain skills, commands, subagents, hooks and MCP servers.

Is there an official list of Claude mods? Anthropic documents the extension points and the plugin system in the Claude Code docs. Community marketplaces and "awesome" lists collect third-party mods; review those before installing.

This guide is independent and not affiliated with Anthropic. Feature names and file locations follow the Claude Code documentation as of October 2026; check the current docs for exact syntax.