Why an agentic CLI and not just another autocomplete?
The first generation of coding assistants (Copilot, Tabnine, Codeium) solved a narrow problem: suggest the next line while you type. Useful, but passive. You remain the operator — the assistant only lends you its right hand.
Claude Code starts from a different premise: the model drives your terminal like a junior engineer with real access to the project. It lists files, reads what it needs, runs tests, creates branches, opens PRs and writes migrations — always asking permission before every irreversible action. The practical difference: you stop describing lines and start describing goals.
This guide is the map I wish I had when I first put Claude Code into production. I'll cover the seven pillars you need to understand to take the CLI out of "curiosity" and into your daily workflow. If you haven't installed it yet, take a quick detour through the Claude Code installation quick start and come back — the rest of this guide assumes claude already runs in your terminal.
Anatomy in one sentence
Claude Code is made of seven layers that fit together:
- Free prompt — what you type, in natural language.
- Slash commands — versioned shortcuts living in your repo (
/commit,/review-pr). - Skills — packaged capabilities with instructions + supporting files.
- Subagents — specialized agents that run in parallel with isolated context.
- Hooks — shell commands triggered by events (before/after every tool use).
- MCP servers — a bridge to external tools (Linear, Slack, your database).
- Plan mode + Memory — planning before execution and persistence across sessions.
Each layer solves a specific problem. You don't need to use them all — but understanding how they fit is what separates people who "play around" from people who actually ship.
Slash commands and skills: lightweight model extension
Slash commands are the cheapest way to extend Claude Code. A markdown file at .claude/commands/deploy.md becomes the /deploy command — when you type it, the content gets injected into the prompt. Perfect for repetitive rituals: reviewing a PR, generating a changelog, deploying to staging, running the start-of-sprint routine.
Skills are the evolution: a directory with SKILL.md + supporting files that the model learns to use on its own when the context calls for it. The critical difference is when each one kicks in — slash commands need explicit invocation, skills get activated by the model when it detects the trigger. I wrote a whole article drawing that line in Slash Commands and Skills: customizing your Claude Code workflow, with examples of when each is the right call.
Subagents: real parallelism inside a session
Subagents are the feature that most changes the perception of speed. When you fire an agent via the Task tool, the main Claude stays free while the subagent runs in its own context. You can launch three subagents in parallel — each investigating a different part of the codebase — and only consume the final summary, protecting the orchestrator's context window.
Practical examples: an Explore subagent doing broad codebase search, a code-reviewer reading the diff with independent eyes, a test-writer drafting tests while you write the feature itself. I dig into architecture, usage and anti-patterns in Subagents in Claude Code: orchestrating tasks in parallel.
Hooks, MCP and the bridge to the outside world
If skills are how you lend the model instructions, hooks and MCP servers are how you lend it actions. Hooks are shell commands executed automatically by the harness — before or after every Edit, Bash, Write. Good use cases: run biome format after every edit, block edits on sensitive files, log every Bash call into an audit file.
MCP servers are servers that expose tools through the Model Context Protocol. With a Linear MCP connected, the model can read and create issues without leaving the CLI. With an MCP for your local Postgres, it queries real schemas before writing a migration. The combination of hooks + MCP is what effectively integrates Claude Code into your daily development workflow — that's where the CLI stops being a toy and becomes team infrastructure.
Plan mode: because good code starts away from the keyboard
Plan mode is the mode where Claude cannot edit anything — it can only read, research and write a plan file for you to approve. It sounds trivial, but it solves the most expensive problem of pair programming with AI: the model starts implementing before it understands. In plan mode, you force the cycle understand → propose → approve → execute.
I turn on plan mode for any task that touches more than one file or mixes domains. Full details, when to turn it off, and plan templates in Plan Mode: planning before execution.
Memory system: persistence across sessions
Every new conversation, the model starts "amnesic" — except for what lives in CLAUDE.md and the project's auto-written memory. Claude Code's memory system is a directory of markdown files the model reads at the start of every session and can update on its own when it learns something durable: team rules, style preferences, history of architectural decisions, context about who the user is and how they prefer to work.
It's the piece that makes Claude Code yours, not just "an assistant that knows the language". Detailed comparisons of how Cursor and Copilot handle (or don't handle) memory live in Claude Code vs Cursor vs Copilot: an honest comparison.
The first productive day
A reasonable flow to go from zero to useful:
- Install and log in — follow the quick start linked at the top of this article.
- Write a minimal
CLAUDE.md— 20 lines about the project: stack, commands to run/test/deploy, team conventions. Worth more than 2000 lines of scattered documentation. - Create 3 slash commands —
/commit,/review,/deploy. Those three cut daily friction immediately. - Connect 1 MCP server — start with what you use most outside the editor (Linear, Jira, your dev database).
- Turn on plan mode for your first real task. Watch what the model got wrong before you approve the plan — that moment is the lesson that pays for everything else.
When not to use it
Claude Code is not a silver bullet. In three scenarios I still prefer to edit by hand: (1) production hot-fixes where every second matters — the context-loading overhead doesn't pay off; (2) critical config files (DNS, IAM, secrets) — the cost of an error is higher than the speed gain; (3) code you're learning — delegating atrophies the intuition you're trying to build. Knowing the limits matters as much as knowing the superpowers.
Next steps
This guide is the doorway. The three main branches dig into each cluster: start with slash commands and skills if your goal is personal ergonomics, with subagents and orchestration if you want speed on large tasks, or with integration into the development workflow if the plan is to adopt Claude Code across the whole team.
