Claude Code

Forget the name for a second. Claude Code is the version of Claude that works on your computer: it opens your files, changes them, creates new ones, and runs multi‑step jobs, while you watch and approve.

Claude Code is Anthropic's agentic coding tool: it reads your codebase, edits files, runs commands, and drives multi‑step engineering work end to end, including commits and pull requests.

The "code" part is historical: it started life as a programmer's tool, and programming is still what it does best. But under the hood it is simply Claude with permission to act, and people use it to rename and reorganise hundreds of files, build reports from folders of documents, and automate fiddly computer chores that a chat window can only describe.

The important mental shift from chat: you are not asking for code, you are delegating a task against a real working tree. It explores the repo itself, so stop pasting files into a prompt and start describing outcomes.

One engine, several front doors

Every surface shares the same engine, so your CLAUDE.md, settings and connected tools work everywhere, and a session can move between them.

Claude now has three ways to act on your behalf, and picking the wrong one wastes an afternoon. Here is the honest routing table.

A fair rule: start with Cowork for everyday document work, and reach for Claude Code when a job is big, repetitive and mechanical (five hundred files to rename by a rule, a folder tree to reorganise, the same edit across dozens of documents). Cowork is covered properly in guide 06.

If you write code, this is not optional kit; it is the primary way to use Claude. The chat window becomes the place you think, and Claude Code becomes the place work happens.

Skip the terminal entirely if you like: the desktop app and the web version (claude.ai/code) are full Claude Code with a normal interface.

Install the CLI, sign in, and add the IDE extension if you live in VS Code or JetBrains. Five minutes, one gotcha.

1. Choose a door. Desktop app for work on your own files; claude.ai/code in the browser for jobs that can run remotely.
2. Sign in with your normal Claude account. It's included with paid plans; usage shares your plan's limits.
3. Grant a folder. Claude Code works inside folders you give it. Start with one experiment folder, not your whole Documents library.
4. Say hello properly. Your first message can just be "look around this folder and tell me what's here". Nothing changes until you ask.

1. Install the CLI and run claude in a repo. Install methods change; take thirty seconds on code.claude.com/docs rather than trusting a blog's copy of last year's command.
2. Authenticate with /login: your Claude subscription or an API key.
3. Add the IDE extension if you want inline diffs; it drives the same engine.
4. Run /init in each repo. It writes a first CLAUDE.md by studying the project (section 05).

Whatever your track: make the first job a read-only one. You learn how it thinks before anything can go wrong.

Look through this folder. Don't change anything yet.
Tell me: what's in here, what looks messy or duplicated,
and what you'd suggest doing to organise it.
Then wait for my go-ahead.

Give me a tour of this codebase: what it does, how it's
structured, the main flows, and where the fragile or
surprising parts are. Read only, don't change anything.

Then a small real job

• Ask for a plan first. "Propose how you'd do X, then wait" costs one sentence and catches misunderstandings before they touch your files.
• Watch the approvals. By default it asks before edits and commands. Read the first few; that's you learning what it wants to do and it learning what you allow.
• Interrupt freely. Esc stops it mid-flow. Correcting early beats letting a wrong plan finish.

• Use plan mode for anything non-trivial. It researches and proposes without touching the tree; you approve the approach, then it executes.
• Scope like a good ticket. "Fix the timezone bug in report generation; the test in tests/reports is failing" outperforms "fix the bug" by miles.
• Let it verify itself. Tell it how to check its own work ("run the tests", "run the linter") and it will loop until green instead of declaring victory early.

A plain text file Claude reads at the start of every session in that folder. It is the single highest-leverage thing to set up: write a rule once, benefit every session.

• Project level: a CLAUDE.md in the folder, for rules about this work. Commit it so colleagues' sessions obey it too.
• Personal level: one in ~/.claude/, for your own preferences everywhere.
• Grow it as you go: start a message with # and Claude Code offers to save that line into memory, so corrections become permanent without opening a file. It also builds memory automatically as it works.

# About this folder
Client deliverables for Harrogate & Co.

## Rules
- Never delete anything; move superseded files to /archive.
- File names: YYYY-MM-DD - Client - Description.
- Finished work goes in /out, drafts stay in /drafts.
- Write in British English, no em-dashes.
- Ask before installing anything.

# Project notes
Next.js app, pnpm, strict TypeScript.

## Commands
- pnpm test (Vitest) · pnpm lint · pnpm typecheck
- Run all three before declaring anything done.

## Conventions
- Server components by default; 'use client' only when needed.
- No new dependencies without asking.
- Conventional commits, small and focused.

## Landmines
- /lib/legacy is frozen: read it, never edit it.

Keep it short and specific. A bloated CLAUDE.md quietly eats context and dilutes the rules that matter; prune it like a garden, not a logbook.

Claude Code's power is exactly why it asks first. The skill is tuning the asking so it's safe without being annoying.

• Default: it requests approval for edits and commands. You can allow one action, or allow that kind of action for the session.
• Allowlists: via /permissions, pre-approve the safe and tedious (running tests, reading files) while keeping prompts for anything destructive.
• Plan mode: research and proposal only, no changes. Ideal for the start of anything big. Shift+Tab cycles permission modes in the terminal.
• Hooks: your own checks that run before or after Claude's actions, and can hard-block them. This is the enforcement layer CLAUDE.md isn't.

You can ignore most of the command list. These earn their keep daily; type /help for the full set on your version.

Also: Esc interrupts without killing the session, and Esc twice steps back through the conversation so you can rewind to before a wrong turn and try a different instruction.

A Skill is packaged expertise: a folder with instructions (and optionally scripts and reference files) that Claude loads by itself when a task matches. Write once, benefit forever.

• Where they live: ~/.claude/skills/ for personal ones, .claude/skills/ inside a project for shared ones. Claude discovers them automatically.
• Almost free until used: only a skill's short description sits in context (roughly a hundred tokens); the body and its bundled files load only when triggered. You can have many without paying for them.
• Sharing: teams distribute skills through Plugins (a shared repository), not by forwarding zip files.
• Same skill, other surfaces: the format works on Claude.ai and the API too, but copies don't sync between surfaces; you install per surface.

Concrete example: a "house style" skill holding your letterhead rules, tone guide and boilerplate. From then on, "write the Jenkins proposal" comes out on-style without you attaching anything.

Concrete examples: a release-checklist skill, a "how we write migrations" skill with a template script, or a code-review skill encoding your team's standards. Anything you'd explain to a new starter is a skill candidate.

MCP (Model Context Protocol) is the plug standard that lets Claude Code use outside systems: databases, browsers, issue trackers, design tools, internal APIs.

• Add servers with /mcp or project config. Once connected, their tools appear to Claude like any other ability, and it decides when to use them.
• The classics: a browser-automation server (Claude tests the UI it just built), a database server (it inspects real schema instead of guessing), and your issue tracker (it reads the ticket itself).
• What this means in practice: Claude Code can be given controlled access to the systems your work lives in, so "check the tracker and summarise what's overdue" becomes a thing it does, not a thing it imagines.
• Scope per project. Wire servers into the projects that need them rather than globally; every connected tool is surface area you're trusting.

Connectors on Claude.ai (Gmail, Drive, Slack and friends) get their own guide: number 04 in this series.

The ceiling on Claude Code isn't one task at a time. Four ways to parallelise, in increasing order of commitment.

• Subagents. Focused specialists (created via /agents) with their own context and tool limits. The lead session delegates, they work, it merges. Great for "review this while I keep building".
• Background agents. Fire off a long job and keep your session; check in on it later.
• Agent teams (swarms). Enable agent teams in settings and Claude stops being one coder and becomes a team lead: it plans, spawns specialist teammates (frontend, backend, tests, review), and coordinates them through a shared task list and inter-agent messages while each works in its own fresh context. Start with research and review jobs (a PR reviewed from three angles, a bug investigated with competing theories) before letting a team write code in parallel.
• Dynamic workflows ("ultracode"). The heaviest setting: /effort ultracode pairs maximum reasoning with automatic orchestration, where Claude writes its own script to fan work out across parallel subagents, some solving, some actively trying to refute the others' findings, until the results converge. Or trigger it per-task by putting ultracode in the prompt. Reach for it when missing something costs more than compute: whole-codebase audits, big migrations, security reviews. Drop back to normal effort afterwards; it is not a quality button to leave on.

The unglamorous trick that makes parallel work safe: git worktrees. One repo, several working copies, one Claude in each, no stepping on each other's edits.

Sessions also move between surfaces: start on your phone, continue on the desktop, or have Dispatch (guide 06) fire off Claude Code sessions from a single instruction and report back.

Four ways to make work happen without you pressing the button. Two keep the current session driving itself; two run with no session open at all, and the machine-on / machine-off distinction decides where those live.

Writing a /goal that works

/goal is the built-in version of the keep-going loop: you state a completion condition, Claude works towards it without you prompting each step, and after every turn a separate small model reads the transcript and rules "met" or "keep going", so the worker doesn't get to grade its own homework. The whole skill is in the condition. That judge can't run commands or read files; it only sees what Claude has surfaced in the conversation, so "done" must be something Claude's own output can prove.

/goal Every file in /reports is renamed to
YYYY-MM-DD - Client - Type and index.xlsx lists all of
them. Prove it: run the listing script and show the
output with zero unmatched files. Constraints: no file
contents change, nothing is deleted. Stop after 25
turns even if unfinished.

• Measurable end state: a test result, an exit code, a file count, an empty queue. "Make the code clean" gives the judge nothing to check and the loop either churns forever or quits early.
• A stated check: tell Claude how to prove it ("npm test exits 0", "git status is clean") so the evidence lands in the transcript where the judge can see it.
• Constraints that block shortcuts: the agent does exactly what the condition measures, so say what must not change ("don't modify the test file"), or the cheapest route to "pass" may be gaming it.
• A turn or time cap for unattended runs. Never leave an open-ended goal running overnight; check progress any time by typing /goal with no argument, and kill it with /goal clear.

A realistic first automation: a weekly routine that reads a reports folder, builds a one-page summary of what changed, and files it in /out. Boring, reliable, and exactly the kind of thing you stop doing by hand.

A realistic first routine: triage. New GitHub issue arrives, Claude reproduces it, labels it, and drafts an analysis comment before you've read the notification.

The habits that separate people who get compounding value from people who bounce off. Hard-earned, freely given.

1. Brief outcomes, not keystrokes. Say what done looks like and how to verify it. Claude Code plans the middle better than you'll dictate it.
2. Plan mode before anything with blast radius. Approving a plan takes a minute; unwinding a wrong hour doesn't.
3. Interrupt early, rewind often. Esc the moment it heads the wrong way; double-Esc to rewind and re-brief. Watching a bad plan complete is a choice.
4. Commit between asks. Small, frequent commits turn "undo Claude's last idea" into a one-liner.
5. Keep an /archive, never delete. Make it a CLAUDE.md rule. You get bold with an agent the day mistakes stop being fatal.
6. Feed corrections into memory. The second time you type the same correction, put it in CLAUDE.md (start the line with #). Sessions should get smarter, not repeat themselves.
7. One task, one session. /clear between unrelated jobs. A session that's been everywhere carries confused context to the next task.
8. Paste the screenshot. UI bug? Screenshot beats prose. It can also run the app and look for itself via a browser MCP server.
9. Ask it to teach you. "Explain what you just did as if to a colleague" after each job. A month of that and you'll know more about your own machine than most IT departments.
10. Give it a way to check its work. A test, a checklist, a "compare against this example". Agents with a definition of done finish; agents without one stop.