🇺🇸 United States · Anthropic Claude Code — The Deep Dive

Status: 🟩 COMPLETE (🟦 LIVING — Claude Code evolves rapidly) Last updated: 2026-06-28 Plain-English tagline: Anthropic’s official CLI agent. Lives in your terminal, reads your project, edits files, runs commands, remembers context across sessions — and is extensible through skills, subagents, hooks, plugins, and MCP servers.


Vendor	Anthropic
Country/origin	🇺🇸 United States (San Francisco)
Recommended for AUS?	✅ Yes — flagship Anthropic developer product; strong privacy; works seamlessly from AUS
Privacy summary	Code processed via Claude API; not used for training; consent-based file access; runs locally; standard Claude API privacy applies
Free tier	Via Claude Pro subscription (limited usage)
Paid tiers	Claude Pro $20 U S D / m o n t h; M a x$ 100 USD/month (5× limits); API billing alternative
First released	Claude Code public release 2024; rapid feature expansion 2024–2026
Last reviewed	June 2026
Official site	https://claude.com/claude-code

In plain English

Claude Code is a program that turns your terminal into an AI-powered workshop. Open it in any folder, and you have Claude — the same model behind claude.ai — sitting there with permission to:

Read and write files in that folder
Run shell commands
Search the codebase
Make web requests
Use any tool you give it access to

You type instructions in natural English (“add a dark-mode toggle to the homepage and deploy it”), and Claude does the work — explaining what it’s doing as it goes, asking when it’s unsure, and stopping if something looks risky. Over a long conversation it remembers everything in the current session; across sessions it remembers what you’ve told it to via memory files.

This is the tool you (George) have been using to build everything in your projects. The St Mark’s Bible Quest webapp, this encyclopedia, every refactor, every bugfix — Claude Code is what’s typing and clicking on your behalf.

It’s not just a smarter autocomplete (like GitHub Copilot). It’s an agent — it loops, plans, takes actions, looks at results, and decides what to do next. Closer in spirit to a contractor you’ve hired than a typeahead suggestion.

Why it matters

For a non-coder building real software, Claude Code is a force multiplier of about 100×. Tasks that would take a self-taught beginner days take 30 minutes with Claude. Tasks that would require hiring a developer cost nothing beyond the Anthropic subscription. The encyclopedia entry on Bible Quest as exemplar reflects what’s possible — but only because Claude Code exists.

Even for experienced developers, Claude Code restructures the workflow. You stop being the typist and become the director. Your value moves from “writing the right code” to “making the right decisions about what to build, what to keep, what to throw away.”

The skill ladder for using Claude Code well isn’t about coding — it’s about clear instructions, calibrated trust, good review habits, and learning when to override.

How Claude Code actually runs

When you launch Claude Code in a folder, here’s the architecture:

Claude Code starts in the terminal. It opens a chat-like prompt.
At startup, it reads your CLAUDE.md file (project root) — this is the “system instructions” for that project.
It loads any global instructions from ~/.claude/CLAUDE.md and ~/.claude/MEMORY.md.
It loads installed plugins, skills, and MCP servers from ~/.claude/ and the project’s .claude/.
You type a message. Claude reads it.
Claude calls tools as needed: Read, Edit, Write, Glob, Grep, Bash, WebSearch, etc.
Each tool call may be auto-approved or require your permission, depending on your settings.
Claude looks at the tool results and decides what to do next — call more tools, or respond to you.
The loop continues until Claude has finished and outputs its final response.

Every tool call is visible. You can see exactly what files were read, what commands ran, what changes were made. There’s no black box.

The six primitives that make Claude Code extensible

Claude Code is designed around six building blocks. Understanding these gives you a mental model for everything else:

Primitive	What it is	Where it lives
CLAUDE.md (memory)	A markdown file Claude reads every session — project conventions, the user’s preferences, project-specific rules	`CLAUDE.md` in a project root, plus `~/.claude/CLAUDE.md` globally
Skills	A `.md` file with frontmatter that teaches Claude how to do a specific task; can be triggered by `/name` slash command or autonomously	`.claude/skills/<name>/SKILL.md`
Subagents	A separate Claude session launched mid-task, with its own context window, prompt, and tools	`.claude/agents/<name>.md` or invoked via the `Agent` tool
Slash commands	Quick shortcuts that trigger skills or canned prompts (e.g. `/help`, `/code-review`)	`.claude/commands/<name>.md` (legacy) or via skills (modern)
Hooks	Shell commands that run automatically on events (before tool use, after session end, etc.)	`.claude/settings.json`
MCP servers	External programs that expose tools (Slack, GitHub, browser control, etc.) to Claude via the Model Context Protocol	Configured in `settings.json`; servers run as separate processes

Plugins are bundles of any of the above, packaged for distribution and reuse. They install with one command and bring all their pieces with them.

1. CLAUDE.md — the project constitution

The single most important file in your project, from Claude Code’s perspective.

CLAUDE.md lives at the project root. Claude reads it at the start of every session and treats its contents as standing instructions — rules, conventions, and context that override defaults.

There are two scopes:

Global (~/.claude/CLAUDE.md) — applies to every session in every project. Your global is currently set up with:
- “George is not a programmer” (default to plain language)
- The cross-project playbook references
- Non-negotiable quality bar (always run npm run build, never expose service_role keys, etc.)
Project (<project-root>/CLAUDE.md) — applies only when Claude Code is opened in that folder. Project CLAUDE.md typically holds:
- Tech stack quick facts
- Where things live (route map, table list, env var names)
- Project-specific gotchas
- Pointers to PROGRESS.md and AGENT_GUIDE.md

Keep both files short. Every line costs tokens in every session, and they add up. If something can live in a memory file (which Claude can fetch on demand) instead of CLAUDE.md (which loads every time), prefer the memory file.

2. The memory system

CLAUDE.md is one piece. The full memory system has three layers:

~/.claude/
├── CLAUDE.md                                   ← global instructions, loaded every session
└── projects/
    └── C--Users-georg/
        └── memory/
            ├── MEMORY.md                       ← index of all memory entries
            ├── user_role.md
            ├── feedback_something.md
            ├── project_bible_study_app.md
            ├── reference_personal_encyclopedia.md
            └── playbook_*.md

MEMORY.md is the index — a short list of pointers like:

## User
- [User is not a programmer](user_role.md) — needs step-by-step guidance
 
## Cross-project playbook
- [Playbook index](playbook_index.md) — start here when beginning any new project

Individual memory files are markdown files with frontmatter:

---
name: user-role
description: George is not a programmer — needs plain language and step-by-step guidance
metadata:
  type: user
---
 
# Body content here...

There are four memory types:

Type	Purpose	Example
user	Who the user is, their role, preferences	”George is not a programmer”
feedback	Corrections/confirmations on how to work	”Never mock the database in tests”
project	Ongoing work, goals, deadlines	”Auth middleware rewrite is for compliance reasons”
reference	Pointers to external systems or resources	”Bugs tracked in Linear project INGEST”

Claude reads MEMORY.md at the start of each session. When something seems relevant, Claude reads the specific memory file. This keeps the per-session cost low while letting the memory base grow large.

What NOT to put in memory: code patterns (Claude can read the code), git history (use git log), debugging recipes (the fix is in the code), or ephemeral task state (use plans/tasks).

3. Skills — teaching Claude specific tasks

A skill is a markdown file that teaches Claude how to do something. It lives at:

.claude/skills/<skill-name>/SKILL.md

Or globally at ~/.claude/skills/<skill-name>/SKILL.md.

A skill file looks like:

---
name: deploy-to-vercel
description: Deploy the current branch to Vercel production
---
 
To deploy this project:
 
1. Run `npm run build` and verify success.
2. Run `git push origin main`.
3. Wait ~90 seconds for Vercel to build.
4. Verify the deployment is live at https://stmarkbible.com.
 
If the build fails, check the function logs in the Vercel dashboard.

You can invoke a skill in two ways:

Explicitly with a slash command: /deploy-to-vercel
Autonomously by Claude — if Claude sees a request that matches the skill’s description, it can choose to apply the skill on its own

Skills can include subfolders with helper files, scripts, templates, etc. that the skill references.

In 2026, skills and slash commands are unified — older .claude/commands/ still works, but .claude/skills/ is the modern approach, and every skill automatically gets a /slash-command interface.

The built-in skills you have access to right now include things like /code-review, /verify, /run, /simplify, /security-review, /init, plus a handful in the cowork-plugin-management and anthropic-skills packs (algorithmic-art, brand-guidelines, docx, mcp-builder, pdf, pptx, xlsx, etc.).

4. Subagents — fresh Claude sessions for sub-tasks

A subagent is launched in the middle of a session via the Agent tool. It’s a separate Claude session — its own context window, its own tools, its own prompt — and it returns a single result to the main session when done.

When to use them:

Context isolation: When a sub-task involves reading many files but you don’t want all those files in the main session’s context.
Parallelism: Run multiple subagents simultaneously for independent searches.
Specialized prompts: A code-review subagent has a different prompt than the main session — fresh perspective.

The subagent types available out of the box (in your setup):

claude — catch-all general agent
Explore — fast read-only search agent
Plan — software architect for implementation plans
general-purpose — for complex multi-step tasks
claude-code-guide — for Claude Code documentation questions
statusline-setup — niche, for configuring the status line

Custom subagents can be defined in .claude/agents/<name>.md with their own description, tool list, and prompt.

5. Hooks — automating behavior on events

Hooks are shell commands that run automatically when something happens in Claude Code. They’re configured in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": "echo 'about to write a file'" }]
    }],
    "Stop": [{
      "hooks": [{ "type": "command", "command": "notify-send 'Claude is done'" }]
    }]
  }
}

The most useful hook events:

Event	Fires when
`PreToolUse`	Before a tool runs — can validate or block
`PostToolUse`	After a tool runs — for logging or follow-up
`Stop`	When Claude finishes a turn — useful for desktop notifications
`UserPromptSubmit`	When you submit a message
`SessionStart`	When the session begins

A PreToolUse hook that returns a non-zero exit code blocks the tool call. This is how you can build hard guards: “never allow rm -rf of the home directory,” “always run prettier after writing a TS file,” etc.

Hooks are deterministic — they’re shell scripts, not Claude prompts — which makes them perfect for automation that must always happen.

6. MCP servers — connecting Claude to external tools

The Model Context Protocol (MCP) is a standardized way for AI agents to use external tools. An MCP server is a separate program that exposes tools to Claude over a standard interface.

You currently have MCP servers configured for things like:

computer-use — control your desktop (screenshot, click, type)
Claude_Preview — drive a browser preview
Claude_in_Chrome — interact with a real Chrome browser
ccd_session_mgmt — session management tools
Plus Canva, scheduled tasks, and others

Adding a new MCP server is usually a config change in .claude/settings.json or via a plugin install. Once added, the server’s tools become available to Claude as if they were native.

The big win of MCP: you don’t have to build custom integrations. If a service has an MCP server, Claude can use it instantly. If a service doesn’t, anyone can write one — it’s a defined protocol with SDKs.

settings.json — the config control center

Most customization happens in two files:

~/.claude/settings.json — your global settings
<project>/.claude/settings.json — project-specific overrides

A typical settings file has sections for:

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Read(*)"],
    "ask": ["Bash(*)", "Write(*)"],
    "deny": ["Bash(rm -rf *)", "Read(~/.ssh/*)"]
  },
  "env": {
    "ANTHROPIC_API_KEY": "...",
    "DEBUG": "true"
  },
  "hooks": {
    "PreToolUse": [...],
    "Stop": [...]
  },
  "mcpServers": {
    "my-server": { "command": "...", "args": [...] }
  },
  "model": "claude-opus-4-7"
}

Permissions are the single most important thing here. The three buckets:

allow — auto-approved without asking
ask — prompts you each time (the default for most tools)
deny — blocked outright

Configuring permissions well dramatically reduces the friction of using Claude Code. Allow the read-only and safe commands you do daily. Keep risky commands in ask. Hard-block the truly destructive ones in deny.

The update-config skill (/update-config) helps you change these without having to edit JSON by hand.

Plugins — bundling everything up

A plugin is a packaged collection of skills, subagents, commands, hooks, output styles, and MCP server definitions. Install it once and all the pieces are wired up.

Public plugin marketplaces (like tonsofskills.com and others) host hundreds of plugins for specific stacks: a “Next.js + Supabase” plugin, a “React Native” plugin, a “data science” plugin. Companies build internal plugins for their own conventions.

In a Cowork session, the user-invocable skills you see (/code-review, /verify, /run, /schedule, etc.) come from installed plugins like cowork-plugin-management and anthropic-skills.

A day in the life with Claude Code

A realistic session, end to end:

You:    "Add a dark mode toggle to the navbar, persist the preference,
         and make sure it works correctly."

Claude: I'll start by looking at how the navbar is structured.
         [Reads app/components/Navbar.tsx]
         [Reads lib/theme.ts]
         I see you're using next-themes already. I'll add a toggle button to the
         navbar, hook it up, and verify it works in both light and dark.
         [Edits Navbar.tsx]
         [Runs npm run build to verify]
         Build passes. Let me also verify in the browser preview.
         [Calls preview_start, preview_click, preview_snapshot]
         The toggle works. Both modes render correctly, preference persists across
         page reloads. Anything else?

You:    "Looks great. Commit and push."

Claude: [Runs git status]
         [Runs git diff]
         [Runs git log -3]
         [Creates commit with a descriptive message]
         [Runs git push]
         Pushed. Vercel will deploy in ~90 seconds.

Notice the rhythm: read context → propose → act → verify → report. Claude doesn’t just write code — it validates. That validation is what makes the agent reliable enough to trust with real work.

The cardinal rules I’ve learned

After many hours of using Claude Code, the things that matter most:

Tell Claude WHY, not just WHAT. “Refactor the auth flow” is a thin prompt. “Refactor the auth flow because the session cookies aren’t being set in production and I think it’s an SSR issue” is rich. Claude makes better choices with richer context.
Let Claude verify its own work. When changes are previewable, Claude should npm run build or use the preview tools and confirm before declaring done. Don’t accept “it should work” — accept “I verified it works.”
Commit often. Every meaningful chunk of work gets its own commit. If Claude breaks something, you roll back to the last commit and try again. This is your safety net.
Use memory ruthlessly. Anything you’ve explained more than twice belongs in a memory file. Future-you (and future-Claude) will thank you.
Don’t be afraid to interrupt. If Claude is going in the wrong direction, hit Esc (or whatever your interrupt key is) and redirect. Long context drifts; short, focused turns are higher quality.
Read the diffs. Even when you trust Claude, glance at what it changed. The pattern recognition you build is worth the seconds it costs.
Permissions = friction. Tune them. Auto-approve the boring stuff you do constantly; keep prompts for the rare risky things.
When in doubt, plan. Use /plan or just ask “before you start, walk me through your plan.” Five minutes of planning saves an hour of cleanup.

When NOT to use Claude Code

Claude Code is incredibly powerful but not universal:

Very tightly scoped trivial tasks. “Rename this variable” — just rename it. Don’t open Claude.
Highly stateful UI work that requires your hands. Drawing, dragging, designing — Claude can describe and edit code, but can’t replace the click-feel of a Figma session.
Tasks where you don’t know what good output looks like. If you can’t review what Claude produces, you can’t catch it being wrong. Either learn the topic first, or restrict the task to something you can verify.
Heavy data work outside the codebase. Big spreadsheet manipulations, ad-hoc data analysis — sometimes plain claude.ai with file uploads is a better fit than Claude Code in a terminal.

For everything else — building, debugging, exploring, learning — Claude Code is the default.

Common gotchas

CLAUDE.md size matters. Every line costs tokens in every session. Treat it like prime real estate.
Permissions can over-prompt. If you get sick of “Approve this tool call?”, spend 5 minutes tuning settings.json.
Memory drift. Memories age. If you tell Claude “always use library X” and later switch to Y, update the memory.
Skill name conflicts. If two skills have the same name (one in your project, one global), the project one wins. Surprising the first time.
MCP servers can be slow to start. Some servers take a few seconds. Don’t panic at the first tool call.
Subagents don’t see your session’s context. They’re fresh sessions. If you tell the main Claude something then spawn a subagent, the subagent doesn’t automatically know — you have to pass it in the spawn prompt.
Hook scripts that block tools also block Claude’s perceived “did it work” check. Make sure deny hooks return clear messages so Claude can understand what was blocked and why.
Slash commands aren’t available in all contexts. Some are terminal-only (e.g. /permissions, /agents). The app surfaces them differently.
The model can be changed mid-session. /model (in the terminal) or via the UI. Different models have different strengths — Opus for hard reasoning, Sonnet for speed, Haiku for cheap throughput.

Sources

Claude Code official docs — canonical reference
Claude Code GitHub — issues, releases
Subagents documentation
Claude Code features and settings reference 2026
Claude Code: Hooks, Subagents & Skills Complete Guide
Inside Claude Code architecture

Tech & AI, Explained

Explorer

claude-code-deep-dive