What Is a Claude Kit? How to Build Your Own Claude Toolkit

“Claude kit” is one of those phrases that means slightly different things depending on who says it. For most developers it means the toolkit you build around Claude: the instructions, skills, subagents, hooks, MCP servers and prompts that turn a general-purpose model into an assistant that knows your codebase and your workflow. For others it’s a specific product name.

This guide covers both meanings, then shows you how to assemble a kit of your own using only the extension points Claude Code ships with. If you want the hub view of everything on this site, start at the Claude kit pillar page.

What “Claude kit” means

A Claude kit is not a single download. It’s a layered setup, and each layer solves a different problem:

Layer	What it is	Problem it solves
CLAUDE.md	A Markdown file Claude reads at the start of every session	“Claude doesn’t know our build commands or conventions”
Skills	Folders with a SKILL.md that Claude loads on demand	“I keep pasting the same checklist or procedure”
Subagents	Markdown files defining specialised assistants with their own context	“Research and log output keep flooding my main conversation”
Hooks	Shell commands (or HTTP/prompt/agent handlers) that run at lifecycle events	“Claude sometimes forgets to format, or touches files it shouldn’t”
MCP servers	Connectors to external tools and data via the Model Context Protocol	“Claude can’t see GitHub, my database or the browser”
Plugins	A package that bundles the layers above for one-command install	“I want to share my setup with my team”
Prompts	Reusable, structured prompts for recurring tasks	“Results vary every time I ask for a code review”

The important distinction: CLAUDE.md content is loaded into every session, while a skill’s body loads only when it’s used. That’s why a good kit keeps CLAUDE.md short and moves procedures into skills.

A short history: Claudekit.cc and Agentkit.best

For a while, Claudekit.cc was also the name of a commercial starter kit for Claude Code. It packaged pre-written skills, slash commands and subagents into an opinionated development workflow.

That product has since been renamed Agentkit.best. The old claudekit.cc domain now redirects to agentkit.best, and the product’s scope widened beyond Claude Code: as of October 2026 its site lists support for Claude Code alongside other agent runtimes such as Codex and Cursor (beta), and it describes a library of 100+ skills, around 95 commands (for example /ak:plan, /ak:cook, /ak:code-review) and dozens of role-based subagents.

If you want a ready-made kit rather than building one, you can look at Agentkit.best (formerly Claudekit.cc). Our Agentkit.best tool page covers what it includes, plus pros and cons, and our Claude kit pricing review compares paid and free kits side by side.

Disclosure: Claudekit.ai may earn a commission if you buy through links marked as sponsored. Claudekit.ai is an independent community project, not affiliated with Anthropic or with Agentkit.best’s makers.

Other projects with “claudekit” in the name

The name is popular, so searches for it surface several unrelated projects. As of October 2026 these include:

• claudekit.app, a browser extension that adds workspace tools to claude.ai (reusable prompts, conversation forks, exports).
• carlrannaberg/claudekit, an MIT-licensed open-source toolkit of custom commands, hooks and utilities for Claude Code on GitHub.

Claudekit.ai (this site) is a separate, independent resource hub and isn’t affiliated with any of them.

Whether you buy a kit or build one, the underlying building blocks are the same open extension points described below. Understanding them makes you a better judge of any kit.

The building blocks of a Claude kit

1. Project memory: CLAUDE.md

CLAUDE.md is the foundation. Claude Code loads it from your project root (and any parent directories) at the start of every session. Run /init inside Claude Code to generate a starter file from your codebase, then trim it.

Keep it factual and short: build and test commands, architecture notes Claude can’t infer, conventions that differ from defaults. Anthropic’s memory docs recommend targeting under 200 lines per CLAUDE.md file, because longer files consume more context and reduce adherence. Personal, uncommitted preferences go in CLAUDE.local.md; preferences for every project go in ~/.claude/CLAUDE.md.

2. Skills

A skill is a folder with a SKILL.md file: YAML frontmatter (most importantly a description that tells Claude when to use it) plus Markdown instructions. Claude invokes it automatically when relevant, or you call it with /skill-name. Skills follow the open Agent Skills standard, so the same format works in other tools too (how the standard works).

Good first skills: a commit-message procedure (start from our commit message prompt), a release checklist, your API conventions. Full walkthrough: Claude Code skills guide. Ready-made examples: our best Claude Code skills roundup and the skills directory, including Anthropic’s skill-creator.

3. Subagents

Subagents are Markdown files in .claude/agents/ (project) or ~/.claude/agents/ (personal). Each has its own system prompt, tool restrictions and optionally a model. Claude delegates to them, and they work in a separate context window, returning only a summary. That keeps verbose work such as test runs or codebase searches out of your main conversation. See the subagents guide.

4. Hooks

Hooks are deterministic. Unlike an instruction in CLAUDE.md, which Claude may or may not follow, a hook runs every time its event fires: format after every edit (PostToolUse), block edits to .env (PreToolUse), send a desktop notification when Claude needs input (Notification). They live in settings.json. See the hooks guide.

5. MCP servers

The Model Context Protocol connects Claude to external systems. A typical kit includes a GitHub server for PRs and issues, a browser automation server such as Playwright MCP, and a docs server such as Context7. Add them with claude mcp add. See MCP servers for Claude.

6. Plugins

Once your kit works, a plugin packages it. A plugin is a directory with a .claude-plugin/plugin.json manifest plus skills/, agents/, hooks/hooks.json and .mcp.json. Teammates install it with /plugin install, ideally from a team plugin marketplace. See the plugins guide.

7. Prompts

Not everything needs to be a skill. A library of well-structured prompts covers one-off or cross-tool tasks: see our prompt library, for example the code review prompt and the bug triage prompt.

How to assemble your own Claude kit

You don’t need everything on day one. This order gives the fastest return for the least context overhead.

Step 1: Install Claude Code and create CLAUDE.md

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

cd your-project
claude

Inside the session, run /init, then edit the generated CLAUDE.md down to what Claude genuinely can’t discover itself. New to the CLI? Follow Getting started with Claude Code.

Step 2: Turn your most-repeated instruction into a skill

Pick the thing you’ve typed more than three times this month. Create it as a personal skill:

mkdir -p ~/.claude/skills/summarize-changes

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed or wants a commit message.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullet points, then list risks
such as missing error handling, hardcoded values, or tests that need updating.

Save that as ~/.claude/skills/summarize-changes/SKILL.md. The !`git diff HEAD` line runs before Claude sees the skill, so the live diff is injected into the prompt.

Step 3: Add one or two MCP servers

Connect the tool you check most often. For GitHub:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

Run /mcp inside Claude Code to confirm it connected. Resist the urge to add ten servers: tool search keeps definitions out of context until needed, but every server is still a running connection, a credential to manage and another source of untrusted content.

Step 4: Add a guardrail hook

A PreToolUse hook that blocks edits to secrets is a sensible first hook. The hooks guide has a complete script.

Step 5: Add a reviewer subagent

Create .claude/agents/code-reviewer.md with read-only tools (Read, Grep, Glob, Bash) and a review checklist. After Claude implements something, ask it to have the reviewer check the diff. A second context that didn’t write the code catches different mistakes.

Step 6: Package and share

When the setup stabilises, move it into a plugin and publish it to a team marketplace, or simply commit .claude/skills/, .claude/agents/, .claude/settings.json and .mcp.json to the repo so everyone gets the same kit.

Example kit layouts

Solo developer kit

• ~/.claude/CLAUDE.md with personal preferences (language, commit style)
• 3–5 personal skills (commit, changelog, PR description)
• MCP: GitHub + Context7
• One Notification hook for desktop alerts
• ccusage to keep an eye on token usage

Team kit (committed to the repo)

• Project CLAUDE.md plus .claude/rules/ for path-specific conventions
• Project skills for deploy, release and migration procedures (with disable-model-invocation: true on anything with side effects)
• Subagents: code reviewer, test runner, security reviewer
• Hooks: formatter after edits, block protected files
• .mcp.json with shared servers (credentials via environment variables, never committed)

Build vs buy

	Build your own	Buy a pre-made kit
Cost	Free (your time)	Paid licence
Fit to your workflow	Exact	Opinionated; you adapt to it
Time to first value	Hours to days	Minutes
Context overhead	Only what you add	Whatever the kit enables
Learning	You understand every piece	Faster start, steeper debugging

A reasonable path: build the basics yourself so you understand the moving parts, then evaluate pre-made kits (our Agentkit.best vs DIY comparison does this in detail) or plugins for the areas where you want a bigger, tested workflow. Our comparison pages help with adjacent decisions such as Claude Code vs Cursor.

Common mistakes

• Everything in CLAUDE.md. Procedures belong in skills; file-type rules belong in .claude/rules/ with path scoping.
• Installing everything you find. Enabled plugins put their skill and agent descriptions in context on every turn, and each MCP server is another process and trust decision. Run /context to see what’s loaded, and /doctor to spot unused extensions.
• Skills with vague descriptions. Claude decides when to load a skill from its description. Put the key use case first.
• Committing secrets. Use ${VAR} expansion in .mcp.json and keep tokens in your environment.
• No verification step. Give Claude something that returns pass/fail (tests, a build, a linter) so its work can be checked.