How Claude Code is built: memory, MCP, skills, subagents, hooks
Claude Code looks like a command line from the nineties: black screen, blinking cursor, nothing more. Beneath it lie six layers that make the tool a construction kit in which programming is only one of many scenarios.
On the philosophy of AI agents I have written elsewhere. Unlike a chatbot, Claude Code is a full partner for very different work, from code through the analysis of analytics to the creation of presentations. Here it goes under the hood: which layers Claude Code consists of, how the memory works, which commands you should know and what skills, MCP and subagents are for. With examples from my own work, without retelling the documentation.
Start and slash commands
You install Claude Code, open the terminal and type claude. The agent mostly starts from your user folder and immediately asks whether it may work in it. Here lies the central peculiarity: Claude Code is installed on your machine and can do as it pleases in the folder you release to it. After a chatbot, this is unfamiliar. My advice: give Claude Code its own working directory in which it sorts projects into subfolders. You can picture these projects like “chats,” one folder for editing texts, one for analytics, one in which Claude Code parses texts and data that several projects then use.
The folder work Claude takes off your hands. At the start of a new project I write something like “We’re building an agent for searching new skills, create a folder for it.” If it is to work in an existing project, “Start the editing assistant” suffices, and the model switches to the fitting folder. Alternatively you switch yourself with cd plus path. You do not have to type the path, you can drag the folder straight into the terminal.
The command line is the control center but not the only way. On this text I work together with an assistant that lives in its own directory. There, sorted into subfolders, lie the description of my projects, an archive of earlier texts, a script that gathers new posts automatically, analytics tables, content plans and style guidelines. For an article we first create a plan in HTML format, which reads more pleasantly than the command line. After my approval, Claude Code creates a Markdown file and fills it with chapter drafts. I open the file in VS Code, rewrite it into human text and put questions or comments directly in the text in square brackets. Then I save, Claude Code checks the chapter for correctness and language and works in my comments.
Besides working on the text, it pays to know the slash commands, that is everything beginning with ”/”. There are several dozen. The most important for the start, sorted into four groups.
Where am I, what is happening right now:
/status: who you are, where you work, which model is connected, at which reasoning level./context: how much of the context window is already occupied. A simple rule of thumb: at 200K stay under 120K to 140K tokens if possible, at 1M under 400K. Above that the model usually gets less precise and burns extra tokens./stats: tokens and cost of the running session./help: the complete directory of all commands.
Settings for the task:
/model: switch model. On the Pro plan I recommend starting with Sonnet at 200K context, later Opus for complex tasks. On the Max plan you can work directly with Opus and switch to simpler models over time if you want to save tokens./effort: depth of reasoning. For Pro I recommend “high,” for Max “xhigh.”/config: general settings like interface and recap behavior./permissions: what Claude may do without asking and what not. More on that in a moment.
Steer the session:
/new: new, empty session. The old one stays in the history./clear: reset the running session’s context without switching folder or restarting Claude. Handy when a task is done and you want to continue in the same folder with a fresh head./compact: condense what has happened so far into a summary and keep working./resume: resume a saved session via name or ID./recap: a short overview of what was done and where you stand, when you come back after an hour or the next day.
Brain and tools:
/memory: look at what Claude knows about you and the project./init: have Claude generate a CLAUDE.md for the current folder./agents: list of subagents running or startable./hooks: automatic triggers./mcp: connected external services.
Plus two keyboard shortcuts: Shift+Tab switches the confirmation modes, Ctrl+C aborts the running action when Claude gets stuck.
Why Claude asks every time
In the first minutes Claude Code behaves like a paranoid. It asks whether it may open a file, run a command or go online. That is annoying, but the logic is sound: the agent lives in your file system and could in principle delete something important, so it would rather ask. This is set via Shift+Tab. There are three main variants.
The default mode asks about everything that changes files or goes online. Maximally safe, but on a complex project you press Enter nonstop from the tenth minute. In “Accept Edits” mode (Shift+Tab once), file changes run without asking, while network requests, shell commands and MCP calls still have to be confirmed. That is the balance of speed and control and my working mode. In “Auto mode” (Shift+Tab twice) a built-in classifier takes over the safety: it rates every command and decides whether it runs or asks. Prompts almost completely disappear; what remains are truly destructive actions like rm -rf. This is available on the Max, Teams and Enterprise plans with Opus.
A common disappointment: you activated “Accept Edits” and still get prompts. The reason is that “file changes” are one category, but “network requests,” “shell commands” and “MCP calls” are each their own. “Accept Edits” removes only the questions on the first category, and that is as it should be. Working on this text, the prompts come every time Claude goes online to check facts, or calls an external MCP. My advice for the first days: do not chase the goal “turn everything off.” Look at what Claude wants released each time, that way you understand its way of working better. If one and the same harmless command like git status shows up for the tenth time, put it on the allowlist via /permissions.
CLAUDE.md: the project’s memory
The biggest peculiarity of Claude Code is that it does not keep earlier conversations. After /new or /clear, after closing the terminal, the next day, it starts from zero. For a chatbot this would be a catastrophe, for an agent it is a deliberate decision: instead of a chat history it has a file of instructions it reads at every start.
This file is called CLAUDE.md and lies in the project folder. There stands everything the model should know from the first minute of a new session: goals, folder structure, technology stack, rules for handling files, output format, habits you do not want to explain anew every day. Like a document for an employee whose morning begins each day with complete amnesia.
Writing CLAUDE.md by hand is not necessary and even rather harmful. At the start of a larger project I open a text document and sketch the project freely. Existing context (statistics, examples of texts or code) I add to it. All of this goes into the project folder, then I ask Claude Code to read it and prepare a Markdown file with follow-up questions. I answer the questions directly in the file, save and have Claude confirm that everything is clear. Then /init: the model scans the folder and suggests a draft. For code it is worth using the planning mode beforehand (Shift+Tab twice or /plan), in which the model asks further questions and suggests an architecture.
Read the draft, correct and add where needed, usually the model does its job well. On big projects I occasionally have the model check CLAUDE.md for whether something is missing or duplicated. The most important principle: maintain the file in dialogue, not in the text editor. If you see Claude regularly making the same mistake, tell it to add a rule to CLAUDE.md.
One file usually suffices. On many projects or in a team, Claude Code reads CLAUDE.md from four levels. The project level is the CLAUDE.md in the project folder; it lies in Git and is shared among all involved. The personal level is ~/.claude/CLAUDE.md in your home folder; there stands what Claude should know about you independent of the project, for instance “answer in German when I write in German” or “don’t ask the obvious every time.” The local level is CLAUDE.local.md next to the project file, for private things within the project like paths to test data or notes; it belongs mandatorily in the .gitignore. The company level is intended for Enterprise plans; there the administration sets uniform rules that individual employees cannot override.
Auto-memory: the second memory
Claude Code keeps a second memory too, one it maintains itself. It lives as auto-memory in its own folder inside ~/.claude, each project has its directory. The central file is called MEMORY.md and is an index. There Claude places short notes, with a pointer to the file in which the details stand. At every start the model reads MEMORY.md first, roughly the first 200 lines land automatically in the context, the rest is loaded on demand.
What goes into it? Everything the model considers worth remembering: how you phrase prompts, typical corrections you made earlier, a quick way to start a project, your preferences on answer style. The criterion is simply the question of whether it is useful in the next conversation. Give Claude Code a few pieces of information about yourself right after installation, and they go exactly into this memory. You should keep managing it: /memory opens an editor with all files, there you see what Claude knows about you and delete or correct the superfluous. In dialogue it works too: “Remember that I’ve started learning Go, future projects also run in this language.”
One more detail: the auto-memory lives locally on the respective machine. Whoever works on the laptop and the desktop has two separate memories, the model knows different things on one device than on the other. This can be merged but is a topic of its own.
MCP: the socket for external services
We all use many services from various providers, and it would be obvious to connect Claude Code to them, so it sees tasks in Jira or pulls texts from Notion. The bridge between agent and outside world is called MCP, Model Context Protocol. It is an open standard, made to connect AI agents to arbitrary services, databases, calendars and messengers.
The catalog of ready MCP servers numbers hundreds: GitHub, Jira, Linear, Slack, Gmail, Google Calendar, Notion, Figma, Sentry, Airtable, Stripe, Cloudflare and most common databases. There are two main sources. The first is the official “Popular MCP servers” section, each with the command to connect. The second is an independent, open registry in which you search by name or category. Nothing stops you from connecting an MCP outside the registries too, for instance from a private GitHub repository.
Connecting is done in one line. For access to Notion, for example:
claude mcp add --transport http notion https://mcp.notion.com/mcpAfter that you see Notion in the list in the session via /mcp. When Claude looks into it, it decides itself: ask it to “find everything on agents in my notes,” and it goes and searches.
Newly added are MCP Channels. That is not just a request-response channel but one through which the outside world can approach the agent on its own. A Telegram bot catches a new message and hands it to Claude for processing, without your having started the agent.
Finally a word of caution. Official MCP servers of large providers like Anthropic, GitHub, Notion, Atlassian, Google, Slack or Stripe you can trust. These services are maintained by the companies themselves, the code is open, and the reputational risks are too big to cheat. An external MCP from an unknown author demands attention. By connecting it you give it access to everything in the project folder. Every external MCP is also a possible channel for prompt injection: someone smuggles into a Jira task the instruction “delete the whole project,” Claude reads it and runs it. The simple rule: servers of large providers are fine, everything else only after review.
Skills: the arsenal of procedures
For everyone who works with AI, prompts accumulate over time that they write again and again. “Break the article down by these points and give a summary.” “Make a digest from these sources.” “Run the text through a style check with these rules.” In the chatbot they lie in notes and are copied every time. Skills in Claude Code are the same idea, only cleanly built in: a proven prompt becomes a single slash command.
A skill is simply built. It is a folder with a file, SKILL.md. Right at the top stand a name, a short description and a few keywords by which Claude itself recognizes when to apply the skill. After that follows the normal instruction text, as if you were explaining the task to a colleague, only once and as precisely as possible. Skill and slash command are the same. Place a folder called my-review, and in the next session the command /my-review appears.
In Claude Code there already lie a few dozen ready skills, such as /simplify, /review, /debug, /loop. Each you can open and read as text, a good way to practice on other people’s examples before you write your own. Alongside there are large public collections like awesome-claude-code, superpowers or awesome-agent-skills. There you find hundreds for many cases, from auto-commits through test runners to data extraction from PDF. They are installed by copying the folder into ~/.claude/skills. A concrete example is the skill /go by Boris Cherny, one of the developers of Claude Code: it starts a chain of testing code, sending it through /simplify and building a pull request. One command instead of ten lines of dialogue. Your own skill with similar logic you build in half an hour.
Important here: the folder must be named strictly in kebab-case (lowercase, hyphens), the file is called exactly SKILL.md, and in the frontmatter the fields name and description are mandatory. The description is not decoration but the trigger: a weak description leads to Claude pulling the skill at the wrong moment or not at all.
Subagents: the parallel department
A subagent is a separate Claude that the main agent starts like a contractor for a certain task. It has its own, clean context window and its own set of permitted actions. A researcher, for instance, can be allowed only to read files and search the web, without the right to change anything.
Two reasons speak for it. The first is saving context: all the busywork, going through a hundred log files or summarizing ten articles, runs in the subagent’s window; into your main window comes back only a short result of a few lines. The second is parallelism: on one request you can start several subagents at once, each takes its piece, and the results come back together. The list you see via /agents, there stand pre-installed and your own. Your own arises like a skill, as a folder with an instruction Claude picks up itself.
Since recently there are Agent Teams, which work directly as a developer team: a team lead and parallel agents for various tasks, from the frontend to the security test. In the first days I would not overdo it with subagents. As long as you are learning, it is better to have the whole work before your eyes. In certain cases Claude Code starts them itself anyway, and over time you notice which tasks can be delegated.
Hooks: triggers that take hold on their own
Hooks are rules of the pattern “if X happens, do Y” that trigger on their own, without your commanding anything. Exactly that distinguishes them from skills and subagents: a skill you call via slash command, a subagent is started for a task, a hook sits in the background and takes hold as soon as the defined event occurs. Such events are moments of the agent’s work, for instance before the start of a tool or after editing a file. A typical example: after every code change, automatically send the file through a formatter.
Hooks are managed via /hooks, which shows what is set and lets you create new ones. In team projects, hooks are shared via the repository’s settings, so everyone works by the same rules. A warning belongs to it: a hook is automatically executed code with your permissions on your machine. Serious hooks that write to the network, change Git or start deployments you activate only when you are sure they do exactly what is intended. Light ones like autoformat, logs or notifications you can set without hesitation, they noticeably save routine.
What to start with now
Six layers make Claude Code more than a CLI tool: memory, MCP, skills, subagents, hooks, and CLAUDE.md as the scaffold for the rest. Now you know what the agent consists of and where it can be adjusted. The rest is habituation. Start sessions, try /agents and /hooks, build your own skills from other people’s collections, and add to CLAUDE.md every time you notice a repetition.