Tommy Lahitte
← Back to Journal

Claude Code Toolkit: Pick the Right Tool for the Job

5 min read

The Big Picture

Claude Code has 7 customization layers. Each solves a different problem. Using the wrong one wastes context, tokens, and your time.

💡
Core principle: Not everything needs to be in context all the time. The best setups use progressive disclosure: load only what's needed, when it's needed.

At a Glance

  • CLAUDE.md · Project readme Claude actually reads · Always loaded
  • Memories · Persistent facts across sessions · Auto / fuzzy
  • Rules · File-type-specific instructions · Loaded on file match
  • Skills · Reusable step-by-step workflows · Loaded on trigger
  • Agents · Specialized personas · Loaded on invocation
  • MCP · Structured access to external services · Loaded on tool call
  • Hooks · Automated shell triggers on events · Guaranteed

Each Tool in 30 Seconds

📄 CLAUDE.md: Your Project's Brain Dump

📄
Loaded: Every single conversation, every time.
  • Think of it as the README that Claude actually reads
  • Put what's particular about your project, not general knowledge
  • Keep it focused: essentials only, no encyclopedias
▶Example content

Architecture decisions, tech stack, naming conventions, folder structure, key patterns unique to your codebase. The Mega Review project's CLAUDE.md is ~13k tokens covering architecture, conventions, and decisions.

💬
Rule of thumb: If Claude keeps getting something wrong about your project, it probably belongs in CLAUDE.md.

🧠 Memories: Persistent Context Across Sessions

🧠
Loaded: Automatically, but you have little control over when.
  • Facts that survive between conversations
  • User preferences, role info, project state
  • Least predictable tool. Claude decides when to recall them.
💬
Use when: You keep repeating the same context every new session. "I'm a backend dev", "We use pytest not unittest", "Our deploy target is ECS".

📏 Rules: File-Specific Guardrails

📏
Loaded: Guaranteed, when you touch a matching file.
  • Triggered by file patterns (e.g., *.md, *.test.ts)
  • Perfect for formatting, structure, and conventions per file type
  • Claude reads the rules before editing the file
▶Example

A rule for *.md files: "Titles must use sentence case. Bold is reserved for key terms. Never use H1 inside the document body." A rule for *.test.* files: "This is our test harness. Here's how to run tests. Consider these project-specific patterns."

💬
Use when: You want consistent formatting or behavior for a specific file type, no exceptions.

⚡ Skills: Reusable Workflows

⚡
Loaded: Description loaded at start, full content on trigger.
  • The most powerful customization tool
  • Step-by-step recipes that Claude executes in order
  • Composable: skills can call other skills
  • Flexible entry: you can drop in at any phase
▶Real example: "Work on Ticket" skill (9 phases)
  1. Select ticket via Jira MCP
  1. Transition ticket to In Progress
  1. Implement code changes
  1. Run tests (calls "Run Tests" sub-skill)
  1. Fix failures, re-test
  1. Commit work
  1. Create branch on GitHub
  1. Create PR (calls "Create PR" sub-skill, which calls "Create PR Content" sub-skill)
  1. Monitor automated checks, address feedback, transition ticket to Code Review
⚠️
Watch out: Don't overskill. If trigger words overlap too much between skills, Claude may fire the wrong one. Keep descriptions distinct.

🎭 Agents: Specialized Personas

🎭
Loaded: When explicitly invoked.
  • Not a workflow, it's a way of being
  • Points the LLM into a role: it thinks and responds as that specialist
  • Great for domain expertise that colors all output
💬
Skill vs Agent: A skill says "do steps 1-2-3". An agent says "you are a security reviewer. Now look at everything through that lens."

🔌 MCP: External Service Access

🔌
Loaded: Tool definitions at start, executed on call.
  • Structured connections to Jira, GitHub, Slack, databases, browsers
  • Configured in your MCP JSON file
  • Tighter permission control than raw command line tools
💬
MCP vs command line: Prefer MCP when available. MCPs give you clear permission boundaries. Fall back to command line only if no MCP exists. Example: use the GitHub MCP to create a PR instead of running gh pr create.

🪝 Hooks: The Boring (but Essential) Stuff

🪝
Loaded: Guaranteed, on specific events.
  • Shell commands that fire on events (before a commit, on file save, etc.)
  • Perfect for mechanical, repeatable checks: code style, formatting, vocabulary
  • Not AI-powered, just pure automation
💬
What are "code style checks"? Tools like ESLint, Prettier, or Ruff that automatically flag or fix formatting issues, unused variables, or style violations. Developers have used these for years. Hooks let Claude trigger them automatically.
💬
Use when: A human developer would use a pre-commit check or automated test pipeline. Hooks handle what doesn't need intelligence.

🧭 Decision Guide

Ask yourself these questions in order. The first "yes" points you to the right tool.

  1. Do I need project-wide context in every conversation? → CLAUDE.md
  1. Do I need specific rules for a file type? → Rules
  1. Do I need a multi-step, repeatable workflow? → Skill
  1. Do I need deep domain expertise or a specialist persona? → Agent
  1. Do I need to talk to an external service (Jira, GitHub, Slack)? → MCP
  1. Do I need a mechanical, automated check (formatting, style)? → Hook
  1. Do I need facts to persist across sessions? → Memories

🧩 Composability

The best setups mix tools together:

  • A skill calls an MCP to fetch a Jira ticket
  • A hook runs code style checks after a skill commits code
  • An agent uses skills as its playbook
  • A skill offloads to sub-skills for PR creation

📦 Progressive Disclosure

Context control = cost control:

  • Description only: Skill triggers
  • On demand: Full skill content, rules, MCP tools
  • Fuzzy: Memories

How Predictable Is Each Tool?

More predictable

  • Hooks, Rules will always fire when conditions are met

Middle ground

  • Skills, MCP, CLAUDE.md have reliable triggers but flexible execution

Less predictable

  • Agents, Memories let the AI decide when and how to engage

Quick Wins to Get Started

  1. Start with CLAUDE.md. Write what's unique about your project
  1. Add rules for your most common file types
  1. Build one skill for your most repeated workflow
  1. Connect one MCP (GitHub or Jira) for external reach
  1. Add hooks for your existing code style and formatting tools
  1. Don't overdo it. Add tools as the need shows up

Claude Code Docs →