Claude Code from zero to production

2026-02-09

The complete Claude Code stack: installation, CLAUDE.md, skills, hooks, permissions, MCP servers, agent teams, Cowork, UI tools, and the workflow that ties them together.

26 · mar 11(1m 2d later) collected everything I know about Claude Code into one place. setup, safety, skills, orchestration, ecosystem. the full stack.

Everything between npm install and a production system. How to install Claude Code, how to teach it your codebase, how to build reusable workflows that compound over time, how to prevent it from breaking things, how to connect it to external services, how to orchestrate parallel work, and the ecosystem growing around it.

1. Setup

Installation

The native installer is the recommended path. npm still works but is deprecated.

BASH Copy

# macOS / Linux / WSL curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell irm https://claude.ai/install.ps1 | iex

Package managers work too (brew install --cask claude-code, winget install Anthropic.ClaudeCode) but don't auto-update.

Verify:

BASH Copy

claude --version

Authentication

Claude Code requires a paid plan — Pro, Max, Teams, or Enterprise. The free tier doesn't include it.

BASH Copy

claude

First run opens a browser for OAuth. Log in, authorize, return to the terminal. Or paste an API key from console.anthropic.com if you prefer metered billing.

First project

BASH Copy

mkdir my-project && cd my-project claude

That's it. Claude reads your project directory, understands the file structure, and is ready to work. No configuration required — everything from here is about making it better.

2. CLAUDE.md — the operating manual

The single most important file in your project. This is the instruction set Claude reads before every interaction. Without it, every session starts from zero. With it, the agent understands your architecture, follows your conventions, and produces code that fits seamlessly into existing patterns.

The difference between "AI-generated code that looks AI-generated" and "code that looks like a senior engineer wrote it" is almost entirely in this file.

What goes in it

Stack declaration — exact framework versions, not just "Next.js" but "Next.js 16.1.6 with Turbopack." Every major dependency and its role. Font choices, icon libraries, theme system.

File structure map — where every type of file lives. Naming conventions for pages, components, actions, utilities. Route organization. Claude needs to know where to put things.

Code patterns — how server components connect to client components. How data flows from database to UI. How mutations work. Return signatures for server actions. The AI follows patterns — give it good ones.

Design system rules — exact color values, typography scale, spacing, border radius, icon sizes. If Claude doesn't know your design system, every component it generates looks different.

Gotchas — framework-specific traps that burned you once. Authentication quirks. Bundler configs that changed between versions. Database constraints. Things that would take 30 minutes to debug if Claude hits them blind.

Where it lives

File Scope

CLAUDE.md Project root — applies to this project

~/.claude/CLAUDE.md User-level — applies to all projects

src/CLAUDE.md Subdirectory — applies only inside that path

Claude reads all of them, most-specific wins. Your personal preferences go in ~/.claude/CLAUDE.md. Project conventions go in the project root. Module-specific rules go in subdirectories.

Start smallYou don't need a 500-line CLAUDE.md on day one. Start with your stack declaration and three conventions. Add to it every time Claude does something wrong — each correction becomes a rule. After a week, the file has organically captured your entire workflow. After a month, it's the most complete documentation your project has ever had.

3. Skills — reusable instructions that compound

CLAUDE.md is static context — it loads every time. Skills are the invocable layer: named workflows that only load when triggered. You write the instructions once, and Claude Code follows them every time you need that workflow.

How skills work

A skill is a markdown file. Plain text. No code, no plugins, no configuration. You write instructions in a file called SKILL.md, put it in a specific folder, and Claude reads it when relevant.

The mechanism is progressive disclosure. When Claude starts, it scans your skills directory and reads only the name and description of each skill — roughly 100 tokens per skill. Lightweight. 50 skills loaded and Claude barely notices. When you type something that matches a skill's description, the full SKILL.md loads into the context window. If nothing matches, no skill fires. You never have to say "use my skill." Claude figures it out.

This is why skills scale. 40 skills don't slow anything down because 39 of them are dormant at any given moment.

Anatomy of a SKILL.md

Every skill lives in its own folder with one required file: SKILL.md.

YAML Copy

--- name: my-skill description: What this skill does and when to trigger it. allowed-tools: Read, Write, Grep, Glob, Bash ---

# My skill

When this skill is triggered:

1. Read the relevant files 2. Analyze the current state 3. Execute the workflow 4. Validate the output 5. Report results

name — what you type after the slash. /my-skill.

description — the most important field. Claude uses it to decide when to auto-activate. Write it like you would naturally ask for help.

allowed-tools — least privilege. Only give the skill the tools it actually needs.

No SDK. No API. No build step. Save the file, use the skill.

Where skills live

Global (all projects) — ~/.claude/skills/[skill-name]/SKILL.md

Project-only — .claude/skills/[skill-name]/SKILL.md

Start global. Move to project-level when a skill gets specialized enough that it doesn't make sense everywhere.

Building your first skill

Pick a workflow you repeat. Committing code. Processing meeting notes. Writing emails. Reviewing documents. Start there. Create the directory.

BASH Copy

mkdir -p ~/.claude/skills/my-skill

c. Write the SKILL.md. Describe the process step by step. Include everything Claude needs to execute correctly — file paths, output formats, validation checks, edge cases.

d. Test it. Open Claude Code. Type /my-skill. It picks up the file immediately. No restart needed.

e. Iterate. The first version won't be perfect. Use it, notice what's missing, update the file. Claude picks up changes on the next invocation. Skills are living documents.

f. Let Claude build the next one. Type /create and describe the workflow. Claude writes the entire skill file. Review it, tweak it, done.

The compounding effect

Skills don't just save time on individual tasks. They compound.

Week 1. You build /commit. Saves 2 minutes per commit. Small win.

Week 2. You build /review and /test. Your code quality pipeline is automated. Hours saved per week.

Month 1. You have 10 skills. /fix, /deploy-check, /scaffold, /session-start. Your entire development workflow is encoded. You're not thinking about process anymore. You're thinking about outcomes.

Month 3. You have 30 skills. Development, operations, content, client management. One command triggers a chain of actions that used to take an afternoon. And then /create starts generating new skills from workflows you notice repeating. The system becomes self-improving.

Skill tips

DescriptionsWrite descriptions like you'd ask a coworker for help. "Review this code" not "Multi-paradigm static analysis tool for code quality assessment." Natural language triggers natural activation.

Keep it leanKeep SKILL.md under 500 lines. Move detailed reference material to separate files in the same folder. Claude can read them when needed. Over 500 lines and Claude starts losing focus on the details.

Dangerous skillsUse disable-model-invocation: true for anything that deploys, sends messages, or modifies production systems. This makes it so the skill only fires when you explicitly type the command — not when Claude decides it should.

Open standardThe Agent Skills format works across 30+ tools: Claude Code, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenAI Codex. Build once, use everywhere.

4. Hooks — catching mistakes before they happen

Hooks are automated rules that intercept Claude's actions before they execute. They catch mistakes proactively instead of reactively. The difference between "I lost two hours debugging a force push" and "the system blocked it automatically."

Hook events

Claude Code exposes 16+ hook events. The critical ones:

Event When it fires

PreToolUse Before a tool executes (Bash, Edit, Write, etc.)

PostToolUse After a tool completes

UserPromptSubmit When you submit a prompt — can transform it

SessionStart When a session begins

SubagentStart When a subagent spawns

PermissionRequest When Claude asks for permission

Hook types

Command hooks — shell scripts. Fast, simple. Good for pattern matching and blocking.

HTTP hooks — POST to a URL. Good for logging, external integrations.

Prompt-based hooks — single LLM call for judgment. "Is this change safe?"

Agent-based hooks — multi-turn with tool access. Full analysis before proceeding.

Essential hooks

Configure in ~/.claude/settings.json or .claude/settings.json:

1. Block destructive deletions. Intercept rm -rf targeting critical paths. Hard block.

2. Block force push. Intercept git push --force. In a fast-moving workflow with hundreds of commits, an accidental force push is catastrophic. Hard block.

3. Block hardcoded secrets. Scan file writes for patterns matching API keys, tokens, passwords. Catches them at write-time, not commit-time. Hard block.

4. Protect environment files. Block writes to .env files. Force use of .env.example with placeholders instead.

5. Warn on debug code. Detect console.log and debugger statements. Warning — allows but flags.

6. Warn on production commands. Detect bash commands containing "production" or "prod" keywords. Warning.

Block vs warnBlock means never allow, period. For irreversible or high-damage actions. Warn means allow but flag. For things that are sometimes legitimate but often mistakes. The goal is a safety net that catches the 1% of catastrophic mistakes while letting the 99% of productive work flow uninterrupted.

The prompt transformation hook

The UserPromptSubmit hook can transform your input before Claude processes it. Practical use: a voice-to-prompt pipeline. You dictate something sloppy into a voice transcription tool — "uh yeah so the revenue graph isn't showing right, there's empty space below it" — and the hook transforms it into a structured, actionable prompt with technical context. The quality of AI output is directly proportional to the quality of input. Automate the quality.

5. Permissions — three tiers of trust

Permission modes

Mode Behavior

default Prompts for approval on first tool use

acceptEdits Auto-accept file edits, prompt for commands

plan Read-only — no edits, no commands

dontAsk Auto-deny unless pre-approved

bypassPermissions Skip all prompts (only in safe environments)

Rule types

Rules evaluate in order: deny, then ask, then allow. A deny rule always wins.

JSON Copy

{ "permissions": { "allow": [ "Bash(npm run *)", "Bash(git status)", "Bash(git log *)", "Read", "Glob", "Grep" ], "ask": [ "Bash(git push *)", "Bash(npm install *)", "Edit", "Write" ], "deny": [ "Bash(rm -rf *)", "Bash(git push --force *)", "Write(.env)" ] } }

The specifier syntax is powerful: Bash(npm run *) matches any npm run command. WebFetch(domain:example.com) restricts web access by domain. mcp__github__* allows all GitHub MCP tools.

What this enables

Routine operations (reading files, running builds, checking git) flow at full speed with zero interruption. Meaningful changes (edits, installs, pushes) get a human checkpoint. Catastrophic actions (force push, recursive delete, env writes) are impossible. You work fast without the anxiety of "what if the AI does something destructive." The guardrails are structural, not behavioral.

6. MCP servers — connecting to everything

MCP 1 servers give Claude access to the world outside your terminal.

1Model Context Protocol. An open standard for connecting AI assistants to external data and services. Each MCP server exposes tools that Claude can call — database queries, API calls, file operations on remote systems.

Configuration

Two places:

BASH Copy

# CLI — adds to your config claude mcp add supabase --command npx -- -y @supabase/mcp-server

# Or manually in .mcp.json (project-scoped, shareable via git)

JSON Copy

{ "mcpServers": { "supabase": { "command": "npx", "args": ["-y", "@supabase/mcp-server"], "env": { "SUPABASE_URL": "${SUPABASE_URL}", "SUPABASE_KEY": "${SUPABASE_KEY}" } } } }

Environment variables expand automatically — secrets stay in your .env, not in committed configs.

Essential MCPs

MCP What it does

Supabase Database operations — tables, queries, RLS policies

GitHub Repo management — issues, PRs, code search

Notion Read and write to your Notion workspace

Context7 Documentation lookup — pulls latest docs for any library

Google Stitch AI design tool — generate UI mockups, export to Figma, pull HTML/CSS into your project

MCP prompts automatically become slash commands — if a server exposes a deploy prompt, you get /deploy for free.

Scopes

Scope Config file Who sees it

Project .mcp.json Everyone on the project (via git)

Local ~/.claude.json Just you, just this project

User ~/.claude.json (user section) Just you, all projects

7. Subagents and agent teams

Two distinct systems for parallel work. Different tools for different problems.

Subagents

Run within a single session. Each gets its own context window, does its work, and reports back. Claude spawns them automatically when it decides to parallelize, or you can configure them explicitly.

Built-in types:

Explore — fast, read-only. For searching codebases, finding files, understanding structure.

Plan — research and architecture. For designing implementation strategies before writing code.

General-purpose — full capabilities. For complex multi-step work.

Custom subagents live in .claude/agents/<name>/SKILL.md. You define the agent's purpose, tools, and constraints — then Claude deploys it when the work matches.

Subagents can run foreground (blocking — Claude waits for the result) or background (concurrent — Claude continues while the agent works). They can use worktrees 1 for safe, isolated experimentation.

1a temporary copy of your git repository that lets the agent make changes without affecting your working directory. If the changes are good, they merge back. If not, the worktree is discarded.

Agent teams (experimental)

Multiple independent Claude Code instances working together. Not subagents within one session — separate sessions with separate context windows that communicate with each other.

One session acts as team lead. Others are teammates. They share a task list and communicate directly. The lead assigns work or teammates self-claim tasks.

BASH Copy

# enable the experimental feature export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Subagents vs teams

Subagents Agent teams

How they run Inside the main session Separate Claude instances

Communication Report back to main agent only Message each other directly

Context Separate window, summary returns Separate window, full independence

Token cost Lower (results summarized) Higher (N context windows)

Coordination Main agent manages everything Shared task list, self-coordination

Best for Focused research, parallel lookups Independent workstreams that need to talk

Rule of thumb: if the workers don't need to communicate with each other, subagents are cheaper and simpler. If worker A's findings change what worker B should do, that's a team.

ExperimentalAgent teams are experimental. No session resumption mid-task, task status can lag, slow shutdown. Powerful for the right problem, but not production-stable yet.

The named rosterInstead of spawning anonymous "Agent 1, Agent 2," give each agent a name, a personality, and explicit boundaries. Personality controls output style — a "paranoid" security reviewer catches different things than a "pragmatic" one. Names make handoff rules readable.

|---|---|---|---|

The flow: Atlas breaks work into tasks, Nova and Forge execute in parallel, Sentinel reviews for risks, Gauge produces test plan and release checklist, Scribe fills gaps whenever anyone hits uncertainty.

Handoff rules prevent collisions: Atlas is the only agent that changes requirements. Nova never touches the schema. Forge never rewrites UI. Sentinel can block a release. Gauge defines "done." Each boundary is a constraint that makes the system predictable.

Playbook — prompts that work

The value of parallel agents is in the prompt design. Each use case below is a template — copy, adapt the file paths and domain to your project, paste.

Research sprint

Four agents researching four options simultaneously. Each produces findings. The lead synthesizes.

Copy

Create an agent team to research state management for our React 19 project. Spawn four researchers:

1. Research Zustand -- API design, bundle size, React 19 compatibility, community ecosystem, and gotchas 2. Research Jotai -- same criteria 3. Research Redux Toolkit -- same criteria, plus migration path from our current Context API setup 4. Research React 19 native (use, useOptimistic, server actions) -- whether we even need a library

When all four complete, synthesize into a comparison table with a clear recommendation based on our project size (medium SaaS dashboard, ~50 components, real-time updates via Supabase).

This works because each agent has a bounded scope, the evaluation criteria are explicit, and the synthesis step has enough context (project size, tech stack) to produce a real recommendation instead of a generic table.

Parallel build with dependencies

Three agents building a feature in sequence. The database agent starts first. The backend agent waits for the schema. The frontend agent waits for the server actions. No file overlap.

Copy

Create a team to build the invoicing feature. Spawn three builders:

1. Database agent -- Create the Supabase migration for invoices table with columns: id, team_id, client_id, status (draft/sent/paid/overdue), amount, due_date, line_items (JSONB), created_at, updated_at. Add RLS policies and indexes.

2. Backend agent -- Create server actions in src/app/actions/invoices.ts following our existing pattern (see src/app/actions/clients.ts). CRUD operations: getInvoices, getInvoice, createInvoice, updateInvoice, deleteInvoice. BLOCKED BY: Database agent (needs schema first)

3. Frontend agent -- Create the invoices page at src/app/dashboard/invoices/ following our page pattern. Include: invoices-view.tsx, invoices-table.tsx, invoices-empty.tsx. BLOCKED BY: Backend agent (needs server actions to call)

Each agent owns different files. No overlap.

The key phrase is "each agent owns different files." File conflicts are the most common agent team failure. Design task breakdowns around file ownership.

Code review committee

Three reviewers reading the same files through different lenses. Independent findings, then synthesis.

Copy

Create a review team for the code in src/app/actions/auth.ts and src/lib/supabase/server.ts. Spawn three reviewers:

1. Security reviewer -- injection vectors, token handling, missing input validation, CORS/CSRF, secrets in code 2. Performance reviewer -- unnecessary DB round trips, missing indexes, N+1 patterns, caching opportunities 3. Test coverage reviewer -- untested code paths, missing edge cases, error handling gaps

Each reviewer produces findings ranked by severity (critical / high / medium / low). The lead synthesizes into a single prioritized review.

Add adversarial instructions to catch false positives: "After initial reviews, share findings with each other and challenge anything you disagree with."

Bug hunt

Five agents, five theories, each trying to disprove their own hypothesis. The one that survives is probably the root cause.

Copy

Users report the app crashes after sending one message. Spawn 5 investigation agents, each pursuing a different theory:

1. Connection pooling -- Supabase Realtime connection leaks. Check src/lib/supabase/client.ts and useEffect cleanup. 2. Memory leak -- missing cleanup in chat components. Event listeners, growing arrays, mount/unmount cycles. 3. Auth token expiration -- Realtime subscription using a token that expires mid-session. Check refresh logic. 4. WebSocket frame limits -- message payloads exceeding Supabase Realtime frame size. Check channel data. 5. Event loop blocking -- synchronous operations in message handling. JSON.parse on large payloads, heavy DOM ops.

Agents should share evidence that supports or refutes their theory. If an agent disproves their own theory, they should say so and help other agents investigate.

The "disprove your own theory" instruction is critical. Without it, agents find confirming evidence for whatever they're looking for. Making them adversarial produces better results.

Migration team

Phased execution — some agents work in parallel, others wait for dependencies.

Copy

Create a migration team for Tailwind CSS v3 to v4. Spawn four agents:

1. Config migration -- Convert tailwind.config.ts to CSS-based @theme configuration. Update postcss.config.js. 2. Import migration -- Update all tailwindcss imports to v4 patterns. Update globals.css directives. 3. Class name auditor -- Scan TSX files for deprecated utilities. Report only — do NOT auto-fix. BLOCKED BY: Config migration 4. Build verification -- Run the build, fix errors. BLOCKED BY: All three above

Agents 1 and 2 work in parallel. Agent 3 waits for 1. Agent 4 waits for all three.

The "report only, do NOT auto-fix" instruction for the auditor is intentional. Automated find-and-replace across class names is error-prone. Review the report, apply manually.

Sizing teams3-5 agents per team. More than 5 creates coordination overhead that outweighs the parallelism. 5-6 tasks per agent — enough to stay productive, not so many that context overflows. And always: 10K tokens on planning saves 500K+ on misdirected execution. Have the lead plan before spawning.

8. The ecosystem

Claude Code is a terminal tool. But the ecosystem around it has expanded fast.

Cowork

Anthropic's "Claude Code without the code." Built into Claude Desktop (macOS), launched January 2026. Same agentic architecture — sub-agents, local file access, long-running tasks — but controlled through a GUI instead of a terminal.

You designate a folder, describe an outcome, and step away. Cowork organizes your downloads, processes receipts into expense reports, synthesizes research into reports, builds Excel files with formulas, creates slide decks from notes. It reads and writes directly to your filesystem.

Cowork Claude Code

GUI in Claude Desktop Terminal

Outcome-oriented ("organize these files") Code-oriented ("build this feature")

Connects to Google Drive, Slack, Salesforce via MCP Connects to dev tools via MCP

macOS only macOS, Linux, Windows

Pro plan and above Pro plan and above

No memory across sessions (yet) Memory via CLAUDE.md and skills

Remote Control

Continue a local Claude Code session from the web or your phone.

BASH Copy

# in your terminal — start remote control claude --remote

Your session becomes available at claude.ai/code and in the Claude mobile app (iOS/Android). The session still runs locally — your machine's filesystem, MCP servers, and project config are all accessible. The phone is just a remote interface.

When to use Remote Control vs OpenClaw:

Use case Best choice Why

Actively building in a repo, want mobile access Remote Control Same coding session, same context

Async requests ("run this workflow", "ship this update") threads/OpenClaw Message-first, works through Telegram/WhatsApp

Non-technical team wants changes in plain English OpenClaw Chat-based interface, low friction

Claude Code on the Web

Run tasks on Anthropic-managed cloud infrastructure. Available in research preview. Different from Remote Control — this doesn't run on your machine at all. Pre-configured environment with common toolchains. Good for CI/CD integration, one-off tasks without local setup, or parallel work that would strain your machine.

IDE integrations

VS Code extension and JetBrains plugin — both bidirectional with the CLI. Open Claude Code in your IDE, or send context from your IDE to an existing terminal session.

9. The UI workflow

This is the one nobody talks about. Four tools that turn Claude Code from a code generator into a design-to-code pipeline.

Google Stitch

First-party Google tool. Generates UI designs from natural language — mobile and web layouts, multiple variants at once, conversational refinement. Exports to Figma with Auto Layout. The MCP integration (community-built, stitch-mcp) lets Claude pull design context and HTML/CSS directly from your Stitch projects into your codebase.

BASH Copy

claude mcp add stitch-mcp --command npx -- -y stitch-mcp

Nano Banana 2

Image generation inside your Claude Code workflow. Powered by Google Gemini. Generates hero images, icons, backgrounds, illustrations — with transparency support, reference images, and style transfer. Works as a standalone CLI and as a Claude Code skill.

GitHub: nano-banana-2-skill

Requires a Google API key for Gemini.

UI UX Pro Max

A design rulesets database that activates automatically during UI work. 50+ styles, 161 color palettes, 57 font pairings, 99 UX guidelines. When Claude is building a component, this skill feeds it proven design patterns instead of letting it improvise. Also has an npm CLI (uipro-cli) for standalone use.

GitHub: ui-ux-pro-max-skill

Superdesign

Template library and AI design agent. Generates mockups and production-ready React + Tailwind code from text descriptions — 10+ variants per prompt. Use it to pull layout patterns for navs, pricing sections, dashboards, settings pages, onboarding flows. MIT licensed.

app.superdesign.dev

The design workflow

Start with a template, not a blank canvas. Pull a layout from Superdesign or generate one from Stitch. Give Claude a visual target. Generate assets as you build. Use Nano Banana 2 for hero images, icons, textures. No context switch to a separate design tool. Iterate in batches. Ask for 3 UI directions with the same requirements but different styles (minimal, bold, data-dense). Keep requirements constant — only change layout and styling per variant.

The "expensive" lookFewer font sizes, fewer colors, more whitespace. Ship a consistent button system (primary, secondary, tertiary) early. Use real UI patterns — tables, empty states, filters, settings — instead of hero-only design. The difference between "designed" and "AI-generated" is restraint.

10. The methodology

Tools matter. Process matters more.

Session management

Every session should start with context recovery. Build a /session-start skill that runs parallel checks: git state, recent changes, environment health, open TODOs, memory from previous sessions. In 30 seconds, you know exactly where you left off. No "where was I?" moments. This is the highest-ROI skill you can create.

Planning before coding

Before writing code, Claude should explore the codebase, identify 2-3 approaches with tradeoffs, recommend one, break it into ordered steps, and assess risks. A planning skill enforces this — it researches, plans, presents, and waits for approval before touching any files.

This prevents Claude from charging down the wrong path and generating hundreds of lines of code you don't want. The 5 minutes spent planning saves 30 minutes of rework.

Incremental commits

Small, focused commits. Each represents one logical change — add a component, fix a bug, update a query. Not monolithic commits with 40 changed files.

Why this matters with AI: large commits are hard to review (too many changes), hard to revert (rolling back affects unrelated things), and hard to debug (which change broke it?). Small commits are safe. Easy to review, surgical rollback, clean git blame.

The workflow: AI makes a focused change, you review the diff (small, fast), commit with descriptive message, next change, repeat.

Memory

CLAUDE.md is static context — it doesn't change between sessions. For dynamic context (what you were working on yesterday, bugs you discovered, decisions you made), maintain a memory directory:

CLAUDE.md — always loaded. Stack, patterns, conventions.

memory/ — topic files. Debugging solutions, architectural decisions, framework gotchas. Updated as you learn.

The session-start skill reads memory files as part of its initialization. Zero ramp-up time between sessions.

11. Cost

Plan Price What you get

Pro $20/month Claude Code access, standard rate limits

Max $100-200/month Higher rate limits, priority access

Teams Per-seat pricing Team features, admin controls

Enterprise Custom Managed policies, SSO, audit logs

Free plan does not include Claude Code.

API key vs subscriptionA Pro subscription gives you flat-rate access. An API key charges per token. For heavy usage (dozens of sessions per day), the subscription is dramatically cheaper. Community members report burning through $300+ of API credits in two days. The math isn't close.

12. Quick reference

Essential files

File What it does

CLAUDE.md Project instructions — stack, patterns, conventions

.claude/settings.json Permissions, hooks, tool rules

.claude/skills/*/SKILL.md Project-scoped skills

.mcp.json MCP server configuration

~/.claude/CLAUDE.md Global instructions

~/.claude/settings.json Global permissions and hooks

~/.claude/skills/*/SKILL.md Global skills

Essential commands

BASH Copy

claude # start a session claude --remote # start with Remote Control claude mcp add <name> # add an MCP server claude --version # check version

Defense in depth

Layer What it catches

CLAUDE.md Wrong patterns, mismatched conventions

Skills Inconsistent workflows, forgotten steps

Hooks Destructive actions, secrets in code, debug statements

Permissions Unauthorized tool use, unsafe commands

Memory Repeated mistakes, lost context

Each layer catches different failures. Together, the probability of a serious mistake reaching production is low — even at high velocity.