The Building Blocks of Claude Code: A Practical Guide for Founders

Most people use Claude Code the same way they use ChatGPT: type a request, read the answer, copy some code. That works fine for one-off tasks. But it barely scratches the surface of what the tool can actually do.

The real leverage in Claude Code is in its customisation layer. There’s a whole system underneath, built from persistent instructions, memory, reusable workflows, specialised agents, external tool integrations, and rules that enforce behaviour mechanically. Once you understand how these pieces fit together, you stop treating Claude Code as a smart autocomplete and start treating it as a programmable collaborator.

I use all of these building blocks daily across my WordPress businesses. This article is my attempt to explain them clearly, without the fluff, for founders who are technical enough to care but haven’t had time to dig through Anthropic’s docs.

CLAUDE.md: Your Persistent Project Instructions

Every Claude Code session loads a set of markdown files before anything else. The most important one is CLAUDE.md. Think of it as a briefing document that Claude reads at the start of every conversation in your project.

These files live in three places. A project-level CLAUDE.md goes in the root of your repository and gets committed to version control. A user-level file at ~/.claude/CLAUDE.md applies to every project you work on. You can also put CLAUDE.md files in subdirectories, and Claude reads them when working in that part of the codebase.

What goes in them? Anything that would otherwise require you to explain it every session. Build commands. Deployment steps. Code style preferences. Architecture decisions and the reasoning behind them. Notes about tricky parts of the codebase. Reminders about what not to do. For a WordPress project, I’d typically include which theme and plugin stack is in use, the WP-CLI commands that work on that server, and any constraints around how posts should be structured.

The distinction from memory (which we’ll get to next) is important: you write CLAUDE.md, and you maintain it intentionally. It’s the canonical source of truth for how Claude should behave in your project.

Memory: Claude’s Auto-Learning System

Memory is different from CLAUDE.md in one key way: Claude writes it, not you. When Claude learns something worth remembering during a session, it can store that as a memory file. These live at ~/.claude/projects/[project-hash]/memory/ on your local machine.

There’s typically a MEMORY.md index file that acts as a table of contents, capped at around 200 lines. It references other files for specific topics: a file about the user’s preferences, another about feedback on past work, another about project-specific context, another for reference material like API docs or schema definitions.

The practical effect is that Claude remembers things across sessions without you having to repeat yourself. If you told it last week that you prefer a particular code pattern, or that a specific integration has a quirk, that context persists. It doesn’t expire when the conversation ends.

Worth noting: memory files can be inspected and edited. They’re just markdown. If Claude stored something incorrect, you can fix it directly. I periodically review mine to prune outdated entries, the same way you’d clean up a notes system.

Skills: Reusable Workflows on Demand

Skills are invokable workflows. You define them once and trigger them with a slash command, like /commit or /deploy or /publish-post. Each skill is a markdown file with YAML frontmatter that describes its name, when to use it, and what tools it needs.

The body of the file is the actual instructions for Claude to follow when the skill runs. It can be as simple as “stage all changes, write a conventional commit message, and push” or as involved as “pull this content brief, draft a post, fetch a stock image from Unsplash, upload it to WordPress, and schedule it for tomorrow morning.” Both are real skills I have set up.

The difference between skills and CLAUDE.md is one of intent. CLAUDE.md is always loaded; it shapes every interaction. Skills are on-demand. You call them when you need that specific workflow. That separation keeps your baseline context lean while still having sophisticated procedures available when you need them.

Skills live in a .claude/skills/ directory (or a user-level equivalent for cross-project skills). They’re files you write and version-control. Over time, a library of well-crafted skills is genuinely valuable, because each one encodes a workflow that used to live only in your head.

Custom Agents: Specialised AI Assistants

Agents take the idea of specialised roles further. Where skills are workflows, agents are persistent personalities with their own context, tool access, and sometimes their own model selection.

You define an agent with an AGENT.md file. In it, you can specify the system prompt that governs the agent’s behaviour, which tools it’s allowed to use, and which model to run it on. A code reviewer might have read-only access to file tools and no ability to execute shell commands. A research agent might have web search and browser automation but no file write access. A deployment agent might run on a faster, cheaper model because the task doesn’t require deep reasoning.

Agents can also run in the background. If you kick off a long research task or a batch content job, you don’t have to sit there waiting. The agent runs independently and surfaces its output when it’s done.

The Agent tool itself (available to Claude in a session) lets you spawn subagents programmatically. So you can build workflows where one agent orchestrates several others, each handling a specialised piece of a larger task. That’s where things get genuinely powerful, and also where it’s worth being deliberate about permissions, because a subagent with write access to production files is a real thing.

MCP Servers: How Claude Connects to the Outside World

Model Context Protocol (MCP) is Anthropic’s standard for connecting Claude to external tools and APIs. Think of MCP servers as plugins that extend what Claude can do beyond your local filesystem.

Popular MCP servers include Playwright (browser automation and scraping), Notion (reading and writing docs), GitHub (pull requests and code reviews), and Gmail (reading and sending email). Each server exposes a set of tools that Claude can call as naturally as any built-in tool. When I ask Claude to check a webpage for broken links, it’s using the Playwright MCP server to open a browser, navigate, and parse the DOM.

Configuration lives in a settings.json file. You specify each server by name, how to launch it (usually a Node or Python command), and any environment variables it needs. The servers themselves can be local processes or remote endpoints.

The MCP layer is what makes Claude genuinely useful for cross-system workflows, not just code editing. If your stack involves five different tools, and you can hook all of them up as MCP servers, Claude becomes a coordination layer that can reason across all of them simultaneously.

Hooks: Deterministic Rules That Claude Can’t Override

Everything discussed so far guides Claude’s behaviour through instructions. Hooks are different. They’re deterministic shell commands that fire automatically at specific points in Claude’s execution, regardless of what Claude wants to do.

There are two main hook points: PreToolUse (before Claude calls any tool) and PostToolUse (after). A PreToolUse hook can inspect the tool call and its arguments, then either allow it, block it, or inject a message. If the hook exits with code 2, the action is blocked entirely. PostToolUse hooks run after the fact, which makes them useful for things like auto-formatting code after every file write, or logging tool usage to an audit trail.

Where skills guide Claude toward good behaviour, hooks enforce hard rules. A hook that blocks any shell command containing rm -rf will catch that command whether Claude is trying to be helpful or has misunderstood your instructions. It’s mechanical enforcement, not AI judgement.

For production environments this distinction matters a lot. I use hooks on projects where certain operations (truncating tables, deleting files outside designated directories, pushing to main) should never happen without an explicit override, not because Claude would normally do those things, but because “never” is a stronger guarantee than “probably won’t.”

Settings and Permissions

Settings in Claude Code follow a three-level hierarchy: user-level (~/.claude/settings.json), project-level (.claude/settings.json), and local overrides (.claude/settings.local.json, typically gitignored). More specific settings override less specific ones.

The permission system controls what Claude can do without asking. There are named modes: plan mode lets Claude propose but not execute; acceptEdits lets it write files but not run commands; bypassPermissions removes interactive prompts entirely (useful for automated pipelines, not for day-to-day use). Below these modes, you can write granular allow/deny rules targeting specific tools and file path patterns.

A typical project setup might allow file reads everywhere, allow writes only within src/, allow shell commands from a specific whitelist, and deny everything else. That’s not paranoia; it’s sensible scoping. Claude will still tell you when it needs to do something outside those bounds.

How It All Fits Together

When you start a Claude Code session, here’s what actually happens. Settings load first, establishing what’s permitted. Then CLAUDE.md files load into context, along with memory from previous sessions. That context shapes every decision Claude makes during the session.

When Claude decides to take an action, it calls a tool. That tool call passes through any matching PreToolUse hooks before executing. If the tool involves an external system (a browser, an API, a database), that goes through the relevant MCP server. After the tool runs, PostToolUse hooks fire.

If you’ve triggered a skill, Claude is following that skill’s specific instructions for the duration of that workflow. If you’ve spawned a subagent, that agent runs with its own context and permission set, isolated from the parent session.

Memory updates happen throughout: observations Claude makes, corrections it receives, references it encounters. The next time you start a session, that context is already there.

The whole system is designed around the idea that Claude should get better at working with you over time, not reset to zero every session. That’s the compounding effect.

These Patterns Aren’t Locked to Claude Code

One thing worth understanding: the specific file formats and tool names are Anthropic’s implementation, but the underlying patterns are becoming industry-wide conventions.

Gemini CLI has its own equivalent of CLAUDE.md. Cursor and Windsurf have rules files and context management. Codex CLI from OpenAI follows similar patterns for project-level instructions. The ideas, persistent context, on-demand workflows, permission scoping, external tool integrations, are converging across tools even if the configs don’t yet transfer 1:1.

MCP itself is an open protocol, not a Claude-only concept. Composio and similar tooling are building universal integration layers that work across multiple LLM backends, the same way a database driver doesn’t care which ORM calls it. The bet that MCP-compatible integrations will work everywhere is looking increasingly sound.

There’s also emerging discussion around AGENTS.md as a cross-platform standard for defining agent behaviour, similar to how robots.txt works for crawlers. Early days, but the direction is toward portability.

The practical takeaway: the time you spend building out this customisation layer, writing good CLAUDE.md files, building skill libraries, configuring MCP servers, is not time spent on a proprietary configuration format that will be obsolete next year. You’re building a system for how you work with AI tools. The specific syntax will evolve; the underlying patterns will stick around.

Start with CLAUDE.md and memory. Add skills as you identify repeatable workflows. Layer in MCP servers when you need Claude to reach outside the filesystem. Add hooks when you need hard guardrails. The architecture is modular. You don’t need all of it at once.