HomeClaude Code CLIThe Claude Code Ecosystem — How Everything Connects
intermediate15 min read· Module 4, Lesson 11

🔗The Claude Code Ecosystem — How Everything Connects

MCP, sub-agents, skills, hooks, rules, and memory — the complete picture

The Claude Code Ecosystem — How Everything Connects

This is the lesson that ties everything together. By now you've learned individual features — CLAUDE.md, Skills, Hooks, MCP, Sub-agents, Memory, and Tools. But the real power of Claude Code comes from combining them into a unified workflow.

1. The Big Picture

Here's how every major Claude Code feature connects to form one coherent system:

┌─────────────────────────────────────────────────────────────┐ │ YOUR PROJECT │ │ │ │ CLAUDE.md (Rules) │ │ ├── Defines how Claude behaves in this project │ │ ├── Coding standards, architecture, banned patterns │ │ └── Read automatically at session start │ │ │ │ │ ▼ │ │ Skills (Custom Commands) │ │ ├── .claude/commands/*.md │ │ ├── Reusable workflows: /review-pr, /deploy, /test │ │ └── Triggered by you or by other skills │ │ │ │ │ ▼ │ │ Hooks (Automated Actions) │ │ ├── Run BEFORE or AFTER Claude actions │ │ ├── Format on save, lint on commit, validate edits │ │ └── Configured in settings.json │ │ │ │ │ ▼ │ │ MCP Servers (External Tools) │ │ ├── GitHub, Slack, databases, Google Drive │ │ ├── Connect Claude to the outside world │ │ └── Configured in .claude/settings.json or ~/.claude/ │ │ │ │ │ ▼ │ │ Sub-agents (Parallel Workers) │ │ ├── Spawned by Claude for complex tasks │ │ ├── Each gets a focused sub-task │ │ └── Results merge back to main agent │ │ │ │ │ ▼ │ │ Memory (Persistent Knowledge) │ │ ├── Auto-saved: build commands, project quirks │ │ ├── Manual: /memory add "always use pnpm" │ │ └── Survives across sessions │ │ │ │ Tools (Execution Layer) │ │ ├── Built-in: Bash, Read, Edit, Write, Glob, Grep │ │ ├── MCP tools: from connected servers │ │ └── The hands that do the actual work │ └─────────────────────────────────────────────────────────────┘

Key insight: Rules flow downward. CLAUDE.md shapes everything below it. Skills use Hooks and MCP. Sub-agents inherit the same rules and tools. Memory persists what was learned.

2. Each Feature — What, When, Why

2.1 CLAUDE.md (Rules)

What it is: A markdown file at your project root that tells Claude how to behave in this specific project — coding standards, architecture decisions, banned patterns, and workflow rules.

When to use it:

  • Starting a new project and want Claude to follow your conventions
  • Your team has specific coding standards (naming, imports, testing patterns)
  • You want Claude to know your project architecture without re-explaining every session
  • You need to ban certain patterns (e.g., "never use `any` in TypeScript")

How to set it up:

Terminal
# Create at project root touch CLAUDE.md # Or let Claude create it claude "create a CLAUDE.md for this project" # Nested rules for subdirectories touch src/backend/CLAUDE.md # backend-specific rules touch src/frontend/CLAUDE.md # frontend-specific rules

Real example (copy-paste ready):

Markdown
# Project: Folowise API ## Tech Stack - Node.js 20, TypeScript 5.4, Express - PostgreSQL with Prisma ORM - Jest for testing ## Coding Standards - Use functional components, no classes - All functions must have JSDoc comments - Use zod for input validation - Never use \`any\` — use \`unknown\` and narrow - Prefer named exports over default exports ## Architecture - src/routes/ — Express route handlers - src/services/ — business logic - src/repositories/ — database access - src/middleware/ — Express middleware ## Testing - Every service must have a corresponding .test.ts file - Use factories for test data, never hardcode - Minimum 80% coverage for new code ## Banned Patterns - No console.log in production code (use logger) - No raw SQL — always use Prisma - No floating promises — always await or void

Common mistakes:

  • Making CLAUDE.md too long (>500 lines). Keep it focused — move detailed docs elsewhere.
  • Contradicting rules (e.g., "use classes" in root, "use functions" in subfolder without being explicit).
  • Forgetting that CLAUDE.md is read every session — stale rules cause confusion.

2.2 Auto Memory

What it is: Claude Code automatically remembers key facts about your project between sessions — build commands, test patterns, project quirks — and you can also manually add memories.

When to use it:

  • You want Claude to remember your preferred build/test commands
  • You've corrected Claude on something and want it to stick
  • You want to store personal preferences (editor style, PR format)
  • A project has non-obvious quirks that Claude keeps forgetting

How to set it up:

Terminal
# View current memories /memory # Add a manual memory /memory add "This project uses pnpm, not npm" /memory add "The staging DB is read-only on weekends" /memory add "Always run migrations before tests" # Claude also auto-saves memories when it learns something important # For example, if you correct it: "No, we use vitest not jest" # It may auto-remember that for next session

Real example:

Terminal
# After setting up a project, tell Claude what matters /memory add "Build: pnpm build" /memory add "Test: pnpm test -- --run" /memory add "Lint: pnpm lint:fix" /memory add "Deploy: ./scripts/deploy.sh staging" /memory add "DB migrations: pnpm prisma migrate dev"

Common mistakes:

  • Adding too many memories. Quality over quantity — Claude can get confused with 50+ memories.
  • Adding conflicting memories. Clean up old ones with /memory.
  • Assuming Claude remembers everything from a conversation — it only saves what it deems important or what you explicitly add.

2.3 Skills (Custom Commands)

What it is: Markdown files in `.claude/commands/` that define reusable workflows you trigger with `/command-name` in Claude Code.

When to use it:

  • You repeat the same multi-step workflow regularly
  • Your team needs standardized processes (PR review, deployment, testing)
  • You want to onboard new team members with guided workflows
  • Complex tasks that need specific instructions every time

How to set it up:

Terminal
# Create the commands directory mkdir -p .claude/commands # Create a skill file touch .claude/commands/review-pr.md touch .claude/commands/deploy.md touch .claude/commands/test-feature.md # Use it in Claude Code /review-pr /deploy /test-feature

Real example — `.claude/commands/review-pr.md`:

Markdown
# Review Pull Request Review the current PR with these criteria: ## Security - Check for exposed secrets or API keys - Validate all user inputs are sanitized - Ensure auth middleware is applied to new routes ## Performance - Flag N+1 queries - Check for missing database indexes on new queries - Verify pagination on list endpoints ## Code Quality - Ensure tests exist for new logic - Check error handling (no swallowed errors) - Verify TypeScript types are strict (no any) ## Output Provide a structured review with: 1. Critical issues (must fix) 2. Suggestions (nice to have) 3. Questions (need clarification) Use the GitHub MCP to read the actual PR diff.

Common mistakes:

  • Making skills too vague ("review this code" instead of specific criteria).
  • Not using `$ARGUMENTS` placeholder for dynamic input.
  • Forgetting that skills can reference other skills and MCP tools — use the full ecosystem.

2.4 Hooks

What it is: Automated actions configured in `settings.json` that run before or after Claude performs specific actions — like formatting code after every edit or linting before a commit.

When to use it:

  • Auto-format code every time Claude edits a file
  • Run linting before Claude makes a commit
  • Validate that certain files weren't accidentally modified
  • Run tests after Claude changes test files
  • Notify you when Claude performs destructive actions

How to set it up:

JSONC
// .claude/settings.json { "hooks": { "afterEdit": [ { "command": "npx prettier --write $FILE", "description": "Auto-format after every edit" } ], "beforeCommand": [ { "matcher": "git commit", "command": "npx eslint --fix .", "description": "Lint before committing" } ], "afterCommand": [ { "matcher": "npm test", "command": "echo 'Tests completed at $(date)'", "description": "Log test completion" } ] } }

Real example — full hooks configuration:

JSONC
{ "hooks": { "afterEdit": [ { "command": "npx prettier --write $FILE", "description": "Format with Prettier" }, { "command": "npx eslint --fix $FILE", "description": "Fix lint issues" } ], "beforeCommand": [ { "matcher": "git commit", "command": "pnpm typecheck", "description": "Type-check before commit" }, { "matcher": "git push", "command": "pnpm test -- --run", "description": "Run tests before push" } ] } }

Common mistakes:

  • Slow hooks that block every edit (e.g., running full test suite afterEdit).
  • Not testing hooks manually before adding them — a broken hook breaks the workflow.
  • Forgetting the `matcher` field for beforeCommand/afterCommand — without it, the hook runs on every command.

2.5 MCP Servers (External Tools)

What it is: The Model Context Protocol lets you connect Claude Code to external services — GitHub, Slack, databases, APIs — giving Claude real tools to interact with the outside world.

When to use it:

  • Read/write GitHub PRs, issues, and reviews
  • Send messages to Slack or Teams
  • Query databases directly
  • Access Google Drive, Notion, or internal wikis
  • Interact with any REST/GraphQL API

How to set it up:

JSONC
// .claude/settings.json { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx" } }, "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-xxxxxxxxxxxx" } } } }

Real example — GitHub + filesystem MCP:

JSONC
{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "ghp_your_token_here" } }, "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects", "/Users/you/docs" ] } } }

Common mistakes:

  • Committing tokens/secrets to git. Use environment variables or a .env file.
  • Not checking MCP server health — run `/mcp` to verify servers are connected.
  • Installing too many MCP servers — each one adds latency. Only connect what you actively use.
  • Forgetting that MCP servers run as local processes — they need Node.js/Python installed.

2.6 Sub-agents

What it is: Claude can spawn focused sub-agents that work on isolated sub-tasks in parallel, then report results back to the main conversation.

When to use it:

  • Reviewing multiple files at once (security review of 10 files)
  • Running parallel analysis (performance + security + code quality)
  • Complex refactoring across many modules
  • Any task that can be split into independent pieces

How to set it up:

Sub-agents are spawned automatically by Claude when it determines a task benefits from parallel work. You can encourage this by:

Terminal
# Ask for parallel work explicitly claude "Review all files in src/routes/ for security issues. Use sub-agents to review each file in parallel." # Or describe the parallel structure claude "Analyze this PR: have one agent check security, another check performance, another check code style."

Real example:

Terminal
# Multi-file review claude "Review these 5 services for error handling: - src/services/auth.ts - src/services/payment.ts - src/services/notification.ts - src/services/user.ts - src/services/order.ts Use sub-agents to review each file in parallel. For each file, check: 1. Are all errors caught? 2. Are error messages descriptive? 3. Are errors logged properly? 4. Is there a catch-all handler?"

Common mistakes:

  • Forcing sub-agents for simple tasks — overhead is not worth it for small tasks.
  • Not giving each sub-agent clear, isolated scope — vague instructions produce vague results.
  • Expecting sub-agents to share state — they work independently.

2.7 Tools (The Execution Layer)

What it is: The actual capabilities Claude uses to do work — reading files, running commands, editing code, and interacting with MCP servers.

When to use it:

Built-in tools are always available:

ToolWhat it doesExample
`Bash`Run shell commands`npm test`, `git status`
`Read`Read file contentsRead src/index.ts
`Edit`Modify files with precise editsChange line 42
`Write`Create new filesCreate config.json
`Glob`Find files by patternFind all *.test.ts
`Grep`Search file contentsFind all TODO comments

MCP tools extend this:

Tool sourceExamples
GitHub MCPCreate PR, read issues, post review
Slack MCPSend message, read channel
Postgres MCPRun query, list tables

Common mistakes:

  • Using Bash when a built-in tool is better (e.g., `cat file.ts` instead of Read).
  • Not knowing which tools are available — ask Claude "what tools do you have?" to see the list.
  • Forgetting that MCP tools only appear after the MCP server is configured and connected.

3. How They Work TOGETHER

This is where the magic happens. Individual features are useful. Combined features are transformative.

Scenario 1: Team PR Review Workflow

Features used: CLAUDE.md + Skills + MCP + Sub-agents + Hooks

┌──────────────┐ │ Developer │ │ runs /pr │ └──────┬───────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ CLAUDE.md loaded │ │ - Review standards defined │ │ - Security checklist included │ │ - Performance thresholds documented │ └──────┬───────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ /review-pr skill triggered │ │ - Reads .claude/commands/review-pr.md │ │ - Defines the review workflow │ └──────┬───────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ MCP: GitHub │ │ - Fetches PR diff │ │ - Reads changed files │ │ - Gets PR description and linked issues │ └──────┬───────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ Sub-agents spawned in parallel: │ │ ┌────────────┐ ┌──────────┐ ┌────────────┐ │ │ │ Security │ │ Perf │ │ Code Style │ │ │ │ Review │ │ Review │ │ Review │ │ │ └─────┬──────┘ └────┬─────┘ └─────┬──────┘ │ │ │ │ │ │ │ └─────────────┼──────────────┘ │ │ │ │ │ Merged Results │ └──────┬───────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ Hook: afterCommand │ │ - Formats the review output │ │ - Posts review via GitHub MCP │ └──────────────────────────────────────────────┘

Setup for this workflow:

  1. `CLAUDE.md` — Define review standards:
Markdown
## PR Review Standards - All new endpoints must have auth middleware - No N+1 queries allowed - Error responses must use standard format - Test coverage must not decrease
  1. `.claude/commands/review-pr.md` — The skill:
Markdown
# Review PR Fetch the current PR diff using the GitHub MCP server. Spawn sub-agents to review in parallel: 1. Security: auth, input validation, secrets 2. Performance: queries, caching, pagination 3. Code quality: types, tests, error handling Merge results and post as a GitHub review. Follow standards from CLAUDE.md.

  1. MCP config for GitHub in `.claude/settings.json`

  2. Hook to auto-format review output

Scenario 2: Daily Standup Automation

Features used: MCP + Memory + Skills + Schedule

┌────────────────────────────────────────────┐ │ 9:00 AM — Schedule triggers │ │ /daily-standup skill runs │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ MCP: Jira │ │ - Fetch tickets updated yesterday │ │ - Get current sprint progress │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ MCP: GitHub │ │ - Fetch merged PRs from yesterday │ │ - Get open PRs needing review │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ Memory │ │ - Recall ongoing projects and blockers │ │ - Remember team preferences for format │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ Claude generates standup summary │ │ - What was done yesterday │ │ - What's planned today │ │ - Blockers and risks │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ MCP: Slack │ │ - Posts summary to #standup channel │ └────────────────────────────────────────────┘

Setup for this workflow:

  1. `.claude/commands/daily-standup.md`:
Markdown
# Daily Standup 1. Use Jira MCP to fetch tickets updated in the last 24 hours 2. Use GitHub MCP to get merged PRs and open PRs 3. Check memory for ongoing blockers 4. Generate a standup summary in this format: ## Done Yesterday - [ticket] description ## Planned Today - [ticket] description ## Blockers - description Post to Slack #team-standup channel.

  1. MCP config for Jira, GitHub, and Slack

  2. Memory stores ongoing project context

  3. Schedule runs this daily at 9 AM

Scenario 3: New Developer Onboarding

Features used: CLAUDE.md + Skills + Memory + MCP + Hooks

┌────────────────────────────────────────────┐ │ New developer runs /onboard │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ CLAUDE.md │ │ - Architecture overview loaded │ │ - Tech stack documented │ │ - Key conventions explained │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ /onboard skill guides them: │ │ Step 1: Explain project structure │ │ Step 2: Walk through key modules │ │ Step 3: Show testing patterns │ │ Step 4: Explain deployment process │ │ Step 5: Set up their local environment │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ MCP: Internal Wiki │ │ - Fetch additional architecture docs │ │ - Get team runbooks │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ Memory │ │ - Store developer's preferences │ │ - Remember their focus areas │ │ - Track onboarding progress │ └──────┬─────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────┐ │ Hooks │ │ - Enforce coding standards on first PRs │ │ - Auto-format to match team style │ └────────────────────────────────────────────┘

Setup for this workflow:

  1. `.claude/commands/onboard.md`:
Markdown
# Onboard New Developer Welcome! Let me walk you through this project. 1. **Project Overview**: Read CLAUDE.md and explain the architecture 2. **Key Files**: Show the most important files and what they do 3. **Data Flow**: Trace a request from API to database and back 4. **Testing**: Show how to write and run tests 5. **Deployment**: Explain the CI/CD pipeline 6. **Local Setup**: Help them get the project running locally Ask what area they'd like to explore deeper. Store their preferences in memory for future sessions.

4. Decision Matrix

When should you use which feature? Use this quick reference:

I want to...Use this featureExample
Set project rulesCLAUDE.mdCoding standards, banned patterns
Create reusable workflowsSkills/review-pr, /deploy, /test-feature
Auto-run actions on triggersHooksFormat on save, lint before commit
Connect external servicesMCP ServersGitHub, Slack, databases, APIs
Parallelize complex tasksSub-agentsReview 10 files at once
Remember across sessionsMemoryBuild commands, project quirks
Run shell commandsBash toolnpm test, git status, docker build
Read filesRead toolView source code, configs
Edit existing filesEdit toolModify code with precise replacements
Create new filesWrite toolGenerate new components, configs
Find files by nameGlob toolFind all *.test.ts files
Search file contentsGrep toolFind all TODO comments, function usages

Combination Cheat Sheet

GoalCombine these
Automated code reviewSkills + MCP + Sub-agents + CLAUDE.md
Team standupSkills + MCP + Memory + Schedule
Developer onboardingSkills + CLAUDE.md + Memory + MCP
Codebase migrationSub-agents + Hooks + CLAUDE.md
Automated testing workflowSkills + Hooks + Bash tool
Documentation generationSkills + Grep + Read + Write

5. Setup Checklist — New Project

Follow these steps to fully set up Claude Code for any project:

Step 1: Create CLAUDE.md

Terminal
# At project root touch CLAUDE.md

Add: tech stack, coding standards, architecture overview, banned patterns, testing requirements.

Step 2: Set up Skills

Terminal
mkdir -p .claude/commands # Create your most-used workflows touch .claude/commands/review-pr.md touch .claude/commands/test-feature.md touch .claude/commands/deploy.md

Step 3: Configure Hooks

JSONC
// .claude/settings.json { "hooks": { "afterEdit": [ { "command": "npx prettier --write $FILE" } ], "beforeCommand": [ { "matcher": "git commit", "command": "npx eslint ." } ] } }

Step 4: Connect MCP Servers

JSONC
// .claude/settings.json (add to existing) { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "your-token" } } } }

Step 5: Add Key Memories

Terminal
claude /memory add "Build: pnpm build" /memory add "Test: pnpm test -- --run" /memory add "This project uses PostgreSQL with Prisma"

Step 6: Test with a Real Task

Terminal
# Try your full workflow claude "/review-pr" # or claude "add a new endpoint for user preferences with full tests"

Verification Checklist

  • CLAUDE.md exists and has project rules
  • .claude/commands/ has at least one skill
  • Hooks auto-format code after edits
  • MCP servers are connected (check with /mcp)
  • Key memories are saved (check with /memory)
  • A real task works end-to-end

6. Architecture Patterns

Pattern 1: The Minimal Setup

For solo projects or quick prototypes:

CLAUDE.md → basic rules Memory → build commands Bash/Read/Edit → built-in tools only

Time to set up: 5 minutes.

Pattern 2: The Team Setup

For team projects with shared workflows:

CLAUDE.md → team standards Skills → /review-pr, /deploy, /test Hooks → format + lint on every edit Memory → project-specific knowledge

Time to set up: 15 minutes.

Pattern 3: The Full Ecosystem

For production projects with external integrations:

CLAUDE.md → comprehensive architecture docs Skills → full workflow library Hooks → format, lint, typecheck, test MCP → GitHub + Slack + DB + monitoring Sub-agents → parallel review and analysis Memory → deep project knowledge

Time to set up: 30 minutes.

Summary

The Claude Code ecosystem is not a collection of separate features — it is a connected system. Each feature amplifies the others:

  • CLAUDE.md sets the rules that everything else follows
  • Skills create repeatable workflows that leverage all tools
  • Hooks automate the tedious parts so you never forget
  • MCP connects Claude to your entire tool ecosystem
  • Sub-agents multiply Claude's capacity for complex work
  • Memory makes Claude smarter about YOUR project over time
  • Tools are the execution layer that makes it all real

Start with the minimal setup. Add features as you need them. The goal is not to use every feature — it is to build the workflow that makes YOU most productive.

Module 4
11/11
Previous
🚀 Advanced Claude Code Workflows
Next
Understanding JSON & Data Formats 📋
Previous
11/11
Next