Mastering Claude Code (Skills, Hooks, MCP & AI Teams)

What Exactly Is Claude Code?

Claude Code is Anthropic's official command-line interface (CLI) tool that brings Claude - one of the most powerful AI models in the world - directly into your terminal. Think of it as having a senior engineer sitting right next to you, who can read your entire codebase, write code, run commands, create commits, review PRs, and even debug production issues.

Unlike ChatGPT or web-based AI tools where you copy-paste code snippets, Claude Code operates directly in your project directory. It sees your files, understands your project structure, reads your git history, and works within your actual development environment. It is not a chatbot - it is an agentic coding tool.

How Is It Different From Cursor, Copilot, etc.?

Installation & Setup (5 Minutes)

Step 1: Install via npm

npm install -g @anthropic-ai/claude-code

Step 2: Navigate to your project and launch

cd your-project
claude

Step 3: Authenticate - On first launch, it opens a browser window for OAuth authentication with your Anthropic account (or you can use an API key).

Step 4: Start coding! - Just describe what you want in plain English. Claude Code reads your project, understands the context, and gets to work.

Requirements: Node.js 18+, an Anthropic account (Max plan or API key), macOS/Linux/Windows via WSL.

The CLAUDE.md File: Your Project's AI Memory

The most important concept in Claude Code is the CLAUDE.md file. This is a markdown file at your project root that Claude reads every time it starts a session. Think of it as a README specifically for your AI assistant.

What to put in CLAUDE.md:

• Project structure - where key directories and files live
• Tech stack - frameworks, languages, versions
• Coding conventions - naming patterns, file organization rules
• Build/test commands - how to run tests, build, deploy
• Common gotchas - things that trip people up in your codebase
• Do NOT and ALWAYS rules - explicit instructions Claude must follow

There are actually 3 levels of CLAUDE.md files:

• ~/.claude/CLAUDE.md - Global preferences (applies to ALL projects)
• ./CLAUDE.md - Project-level instructions (committed to git, shared with team)
• ./.claude/CLAUDE.local.md - Personal overrides (gitignored, just for you)

Essential Keyboard Shortcuts

What Are Skills?

Skills are reusable, shareable prompt templates that extend Claude Code's capabilities. Think of them like macros or recipes - you define a workflow once, and then invoke it with a simple slash command. Instead of typing "please review this PR, check for security issues, performance problems, and style violations" every time, you just type /review-pr.

Analogy: Think of Skills like saved templates on WhatsApp Business - restaurants have pre-written replies for common questions. Similarly, Skills are pre-written AI workflows for common development tasks.

Built-in Skills

Claude Code comes with powerful built-in skills:

• /commit - Analyzes all staged/unstaged changes, generates a meaningful commit message following your repo's conventions, stages files, and creates the commit. It even reads recent commit history to match the style!
• /review-pr - Does a comprehensive code review of a pull request. It checks for bugs, security issues, performance problems, and style violations. Way more thorough than a human review at 2 AM.
• /pdf - Reads and analyzes PDF files. Useful for understanding design docs, specifications, or research papers.

Creating Your Own Custom Skills

This is where it gets really powerful. You can create your own skills for repetitive workflows. Skills are markdown files stored in specific directories.

Skill File Locations:

• ~/.claude/skills/ - Personal skills (available in all projects)
• .claude/skills/ - Project skills (committed to git, shared with team)

Example: Custom /deploy skill

# .claude/skills/deploy.md

Deploy the current branch to staging.

Steps:
1. Run all tests first: npm test
2. Build the project: npm run build
3. Check for any TypeScript errors: npx tsc --noEmit
4. If all pass, deploy: flyctl deploy --remote-only
5. After deploy, run health check: curl https://api.example.com/health
6. Report the deployment status

Example: Custom /write-tests skill

# .claude/skills/write-tests.md

Write comprehensive tests for the specified file or component.

Rules:
- Use the existing test framework in the project
- Follow the testing patterns already established in the codebase
- Include edge cases, error cases, and happy path tests
- Mock external dependencies
- Aim for at least 80% coverage of the target file
- Run the tests after writing to make sure they pass

How Skills Actually Work Under the Hood

When you type a slash command like /deploy, Claude Code:

1. Searches for a matching skill file (deploy.md) in skill directories
2. Reads the markdown content of the skill file
3. Injects it as a system-level prompt into the current conversation
4. Claude then follows those instructions using its full tool capabilities
5. Any arguments you pass after the slash command are also forwarded

You can pass arguments too: /write-tests src/utils/auth.ts - the filename gets passed as context to the skill.

Pro Tips for Writing Great Skills

• Be specific - Don't say "write good tests." Say "write tests using Jest, mock all API calls, include at least 3 edge cases."
• Include constraints - "Do NOT modify existing files" or "ALWAYS run tests after changes."
• Reference project conventions - "Follow the patterns in src/tests/example.test.ts."
• Chain steps - Skills work best when they have clear sequential steps.
• Share with your team - Put skills in .claude/skills/ and commit them. Everyone gets the same AI workflows.

What Are Hooks?

Hooks are custom scripts that run automatically before or after Claude Code executes specific tools. They are like git hooks (pre-commit, post-commit) but for AI tool execution. Hooks give you fine-grained control over what happens when Claude reads files, edits code, runs bash commands, or performs any other action.

Analogy: Think of a security guard at a building entrance. Before anyone enters (pre-hook), the guard checks their ID. After they leave (post-hook), the guard logs their exit time. Hooks do the same for Claude Code's actions.

Types of Hooks

• PreToolExecution Hooks - Run BEFORE Claude executes a tool. Can modify the input, block the action, or add logging. Use cases: preventing edits to protected files, auto-formatting code before writes, blocking dangerous bash commands.
• PostToolExecution Hooks - Run AFTER Claude executes a tool. Can process the output, trigger notifications, or perform cleanup. Use cases: auto-running linters after file edits, sending Slack notifications on commits, logging all bash commands.
• Notification Hooks - Triggered when Claude wants to notify you (e.g., background task completed). Use cases: desktop notifications, sound alerts, Slack messages.

How to Configure Hooks

Hooks are configured in your .claude/settings.json file (project-level) or ~/.claude/settings.json (global).

// .claude/settings.json
{
  "hooks": {
    "PreToolExecution": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"Editing file: $CLAUDE_FILE_PATH\""
          }
        ]
      },
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/validate-command.sh"
          }
        ]
      }
    ],
    "PostToolExecution": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx eslint --fix $CLAUDE_FILE_PATH"
          }
        ]
      }
    ],
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code finished!\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Hook Execution Flow

Understanding the flow is crucial:

1. Claude decides to use a tool (e.g., Edit a file)
2. Pre-hooks run - If any pre-hook exits with a non-zero code, the tool execution is BLOCKED
3. Tool executes (if pre-hooks passed)
4. Post-hooks run - These see the tool's output and can act on it
5. Claude sees the final result (including any hook modifications)

Key insight: Pre-hooks can BLOCK tool execution by returning a non-zero exit code. This is your safety mechanism. You can prevent Claude from editing production configs, running dangerous commands, or modifying protected files.

Real-World Hook Examples

• Auto-lint after every edit: Post-hook on Edit tool that runs ESLint/Prettier on the modified file
• Protected files guard: Pre-hook on Edit that blocks changes to .env, package-lock.json, or migration files
• Bash command logger: Pre-hook on Bash that logs all executed commands for audit
• Test runner: Post-hook on Edit that auto-runs related tests when test files change
• Desktop notification: Notification hook that plays a sound when a long-running task finishes
• Commit message validator: Pre-hook on the commit skill that ensures messages follow Conventional Commits format

What is MCP (Model Context Protocol)?

MCP is an open protocol created by Anthropic that allows AI models to connect with external tools and data sources. Think of it like USB-C for AI - a universal standard that lets Claude Code plug into any external service: databases, APIs, file systems, browsers, monitoring tools, and more.

Without MCP, Claude Code can only use its built-in tools (Read, Edit, Bash, Grep, etc.). With MCP, you can give it access to your Jira board, Slack channels, database queries, GitHub issues, Google Drive, Figma designs - virtually anything.

Analogy: Imagine a chef (Claude) who can only cook with ingredients already in the kitchen. MCP is like Swiggy Instamart - now the chef can order any ingredient from any store in real-time while cooking.

How MCP Architecture Works

MCP follows a client-server architecture:

• MCP Client - Claude Code itself acts as the client. It discovers available servers and their tools, then calls them as needed.
• MCP Server - A lightweight program that exposes specific capabilities. Each server can provide multiple tools. Servers can be written in any language (Python, Node.js, Go, etc.).
• Transport - Communication happens over stdio (local servers) or SSE/HTTP (remote servers).

The flow: Claude needs data from Jira → calls the Jira MCP Server → server queries Jira API → returns structured data to Claude → Claude uses it in its response.

Configuring MCP Servers

MCP servers are configured in your settings files:

// .claude/settings.json (project-level)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-token"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

You can also use ~/.claude/settings.json for global MCP servers that should be available in all projects.

Popular MCP Servers You Should Know

Building Your Own MCP Server

You can create custom MCP servers for internal tools. A basic MCP server in Python looks like this:

# my_mcp_server.py
from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-internal-tools")

@server.tool()
async def get_deploy_status(environment: str) -> str:
    """Check deployment status for an environment"""
    # Your internal API call here
    status = await check_deployment(environment)
    return f"Deploy status for {environment}: {status}"

@server.tool()
async def query_metrics(service: str, metric: str) -> str:
    """Query Prometheus metrics for a service"""
    data = await prometheus_query(service, metric)
    return format_metrics(data)

if __name__ == "__main__":
    server.run()

Then configure it in settings.json and Claude can use your internal tools seamlessly!

The Multi-Agent Concept

This is the most revolutionary feature of Claude Code. Instead of having one AI assistant doing things sequentially, you can spawn multiple Claude Code agents working in parallel - like having a team of developers all working on different parts of your project simultaneously.

Analogy: Imagine you are running a dhaba (restaurant). A single chef cooking everything one by one is slow. But what if you had 5 chefs - one making rotis, one on dal, one on sabzi, one on salad, one on dessert - all working in parallel? Your order comes out 5x faster. That is multi-agent Claude Code.

Background Tasks with Ampersand

The simplest way to run parallel agents is using the background task feature. You can tell Claude Code to run something in the background while you continue working.

How it works:

• Start Claude Code in your main terminal and give it your primary task
• Open another terminal, cd into the same project, and run claude again
• Now you have 2 agents working on the same codebase independently
• Each agent has its own context and conversation history
• They can even read each other's changes (since they share the filesystem)

Git Worktrees: The Safe Multi-Agent Strategy

Running multiple agents on the same directory can cause file conflicts. The solution? Git worktrees.

A worktree is like a parallel universe of your git repo - same repository, different working directory, different branch. Each agent gets its own worktree, so they never step on each other's toes.

Using worktrees in Claude Code:

• Type /worktree or ask Claude to "start a worktree"
• Claude creates a new worktree in .claude/worktrees/ with a fresh branch
• All work happens in isolation - no conflicts with other agents
• When done, merge the branch back into main

The AI Team Pattern:

# Terminal 1: Agent working on new feature
cd my-project
claude
> Create a worktree and implement the payment integration

# Terminal 2: Agent fixing bugs
cd my-project
claude
> Create a worktree and fix the 5 bugs in the issue tracker

# Terminal 3: Agent writing tests
cd my-project
claude
> Create a worktree and write tests for the auth module

# Terminal 4: Agent doing code review
cd my-project
claude
> Review PR #42 and leave detailed comments

Headless Mode for CI/CD and Automation

Claude Code can run in headless mode - no interactive terminal needed. This is perfect for CI/CD pipelines, cron jobs, and automated workflows.

# Run a one-shot command (non-interactive)
claude -p "Analyze this codebase and create a summary of all API endpoints"

# Pipe input from a file
cat bug-report.md | claude -p "Analyze this bug report and suggest a fix"

# Use in CI/CD - auto-review PRs
# .github/workflows/ai-review.yml
# on: pull_request
# steps:
#   - uses: anthropics/claude-code-action@v1
#     with:
#       prompt: "Review this PR for bugs, security, and performance"

There is even a GitHub Action (anthropics/claude-code-action) that runs Claude Code in your CI/CD pipeline to auto-review PRs, generate changelogs, or enforce code standards.

The Dream Team Setup

Here is how a solo developer can build an entire "AI engineering team":

Cost Note: Each agent session uses tokens independently. Running 4 parallel agents costs roughly 4x. But the time savings (from hours to minutes) makes it extremely worthwhile for important projects.

The Art of Prompting Claude Code

Claude Code is incredibly capable, but the quality of its output depends heavily on how you communicate with it. Here are battle-tested prompting strategies:

• 1. Be Specific About What You Want
  Bad: "Fix the login bug"
  Good: "The login form on /auth/login throws a 401 error when the email has a + character. The issue is likely in the email validation regex in src/utils/validators.ts. Fix it and add a test case."
• 2. Give Context About Why
  Bad: "Add a retry mechanism"
  Good: "Our payment webhook handler fails silently when Stripe's API returns a 503. We need exponential backoff retry with max 3 attempts, because during Black Friday we lost 200 orders due to this."
• 3. Reference Existing Patterns
  Bad: "Create a new API endpoint"
  Good: "Create a new GET /api/orders endpoint following the same pattern as the existing /api/users endpoint in src/routes/users.ts. Use the same middleware chain, error handling, and response format."
• 4. Set Boundaries
  Bad: "Refactor the auth module"
  Good: "Refactor the auth module to use JWT instead of sessions. Only modify files in src/auth/. Do NOT change any API contracts. Do NOT modify the database schema. Run tests after each change."
• 5. Break Large Tasks Into Steps
  Bad: "Build a complete user management system"
  Good: "Let's build user management in 4 steps. Step 1: Create the database schema for users and roles. Show me the migration before applying."

Plan Mode: Think Before Acting

Press Shift+Tab to toggle Plan Mode. In this mode, Claude analyzes the problem, creates a plan, and shows it to you BEFORE making any changes. This is invaluable for complex tasks.

When to use Plan Mode:

• Large refactoring tasks that touch many files
• When you are unsure about the approach and want to review the plan first
• Architecture decisions where you want to see multiple options
• When working on critical production code where mistakes are costly

Real-World Workflow 1: Code Review

# Review a specific PR
claude
> Review PR #42 on GitHub. Check for:
  - Security vulnerabilities (SQL injection, XSS, auth bypass)
  - Performance issues (N+1 queries, missing indexes)
  - Error handling gaps
  - Missing tests for new code paths
  - Code style violations
  Leave detailed comments on specific lines.

Claude will use the GitHub MCP server (or gh CLI) to fetch the PR, analyze every changed file, and leave inline comments - just like a senior engineer would.

Real-World Workflow 2: Debugging Production Issues

# Debug with real error context
claude
> We are getting this error in production:
  "TypeError: Cannot read property 'email' of undefined"
  at src/handlers/notification.ts:47
  
  This started happening after yesterday's deploy (commit abc123).
  Check what changed in that commit, trace the data flow,
  and find the root cause. Don't fix it yet - just explain.

Claude will look at the git diff for that commit, trace the code path, identify where the null reference occurs, and explain the root cause clearly before you decide how to fix it.

Real-World Workflow 3: Refactoring Legacy Code

claude
> I need to refactor src/services/orderService.js from a 
  1200-line monolith into smaller, testable modules.
  
  Rules:
  - Don't change any external API contracts
  - Don't change database queries
  - Split into logical modules (validation, pricing, shipping)
  - Each module should be independently testable
  - Make ONE change at a time and run tests between each change
  - If any test fails, revert and try a different approach

Real-World Workflow 4: Writing Tests

claude
> Write comprehensive tests for src/utils/paymentCalculator.ts
  
  Look at the existing test patterns in src/__tests__/
  Include:
  - Happy path for all public methods
  - Edge cases: zero amounts, negative numbers, currency rounding
  - Error cases: invalid inputs, network failures
  - Integration test with mock Stripe API
  - Aim for 95% line coverage
  - Run tests and fix any failures

Prompting Mistakes to Avoid

• Mistake: Being too vague - "make the code better"
• Mistake: Not providing constraints - Claude might refactor your entire codebase
• Mistake: Asking for too many things at once without structure
• Mistake: Not using /compact when the conversation gets long (context pollution)
• Mistake: Ignoring CLAUDE.md - put your project rules there so you do not repeat them every session
• Mistake: Not checking the output - always verify Claude's changes before committing

VS Code Integration

Claude Code integrates seamlessly with VS Code through the Claude Code VS Code Extension. Once installed, you get:

• Embedded Terminal - Claude Code runs directly in VS Code's integrated terminal. No need to switch between windows.
• File Sync - When Claude edits files, VS Code immediately shows the changes. You see real-time diffs.
• Diagnostics Integration - Claude can read VS Code's language server diagnostics (TypeScript errors, ESLint warnings) and fix them.
• Code Actions - Select code in VS Code, right-click, and "Ask Claude" to explain, refactor, or fix it.
• Inline Diff View - Before accepting changes, you see a clean side-by-side diff of what Claude wants to change.

To install: Open VS Code Extensions panel, search for "Claude Code", and install. Then open a terminal and type claude.

JetBrains Integration (IntelliJ, WebStorm, PyCharm)

Claude Code also works with JetBrains IDEs through their integrated terminal. While the integration is not as deep as VS Code, you still get:

• Full terminal access within the IDE
• File changes appear instantly in the IDE editor
• Git integration works through JetBrains' built-in VCS tools
• You can use JetBrains' diff viewer to review Claude's changes

Advanced Feature: Task Management

Claude Code maintains a mental model of complex tasks using its internal task tracking. For large projects, you can:

• Break work into subtasks: "We need to build a payment system. Let's plan the tasks first." Claude will create a task breakdown and work through them systematically.
• Resume sessions: Use claude --resume to continue a previous conversation with all context preserved.
• Compact context: When conversation gets long, use /compact to compress earlier messages while preserving key decisions and context.

Advanced Feature: Permission System

Claude Code has a granular permission system that controls what tools can do:

• Allow - The tool can run freely (e.g., Read files, Grep)
• Ask - Claude asks for permission before running (e.g., Bash commands, Edit files)
• Deny - The tool is completely blocked

You can configure permissions per-project in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test)",
      "Bash(npm run lint)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)"
    ]
  }
}

This ensures Claude can freely search and read your codebase but always asks before running destructive commands. Safety first!

Advanced Feature: Model Selection

Claude Code supports multiple models, and you can switch between them mid-conversation:

• Claude Opus 4.6 - The most capable model. Best for complex refactoring, architecture decisions, and tasks requiring deep understanding. Uses more tokens (costs more) but gives the best results.
• Claude Sonnet 4 - The balanced model. Great for everyday coding tasks - fast, capable, and cost-effective. Best choice for 80% of tasks.
• Claude Haiku - The speed demon. Best for simple tasks like formatting, renaming, and quick searches. Very fast and cheap.

Switch models with /model command. Pro tip: Start with Sonnet for exploration, switch to Opus for the critical implementation.

Cost Management Tips

• Use /cost to monitor spending per session
• Use /compact regularly to reduce context size and save tokens
• Write good CLAUDE.md files so Claude does not waste tokens figuring out your project structure
• Use Sonnet for simple tasks, Opus only for complex ones
• Use /clear between unrelated tasks in the same session
• Max plan subscribers get 5x more usage than Pro - worth it if you use Claude Code daily