Claude Code, part 2: The everyday workflow

Part 1 got Claude Code installed. This part covers the habits that make it reliable: controlling what it may do, planning before editing, undoing mistakes, managing context, and giving it lasting knowledge of your project.

Permission modes

The permission mode decides what Claude can do without asking. Press Shift+Tab to cycle modes during a session.

Mode	Behaviour	Good for
Auto	A background classifier reviews actions and blocks risky ones instead of asking you. This is the built-in starting mode for interactive sessions on v2.1.283+.	Most day-to-day work
Manual (default)	Asks before file edits and shell commands	Unfamiliar or sensitive repos
Accept edits (acceptEdits)	Edits files and runs common file commands (mkdir, mv, cp) freely; asks for other commands	Fast iteration you’ll review in git
Plan (plan)	Reads and explores but doesn’t edit source files	Designing a change before making it
dontAsk	Denies anything that would need a prompt	Locked-down CI
bypassPermissions	Skips prompts	Only inside throwaway containers or VMs

To change the mode sessions start in, set defaultMode in your settings (see below).

Plan, then build

For anything bigger than a one-line fix, separate thinking from doing:

1. Switch to Plan mode (Shift+Tab) and describe the goal:

   I want to add rate limiting to the public API. Look at how requests flow
   through src/server and propose a plan. Don't change anything yet.

2. Review and refine the plan. Ask about edge cases, push back, and narrow the scope.

3. Switch back to Auto or Accept edits and say “implement the plan”.

4. Make it prove the result:

   write tests for the limiter, run the whole suite, and fix anything that fails

Giving Claude a way to verify its own work (tests, a build, a linter, a screenshot) is the single biggest quality lever.

Undo with checkpoints

Before every file edit, Claude Code snapshots the file. Press Esc twice to rewind to an earlier point in the conversation, or just say “undo that”.

Checkpoints are separate from git and survive resuming a session. They don’t cover side effects outside your files, such as database writes, deployments or API calls. Those are what permissions are for.

Steering mid-task

• Esc stops Claude immediately and waits for your next instruction.
• Typing while it works queues your message. Claude reads it after the current tool calls finish and adjusts without stopping.

You don’t need perfect prompts. Start with the goal, watch, and correct (“not there, the bug is in session handling”).

Context: what Claude remembers right now

Everything in the conversation shares one context window: your messages, files read, command output, CLAUDE.md and loaded skills.

Command	Use it to
/context	See what’s using space
/compact focus on the API changes	Summarise the conversation now, keeping what matters
/clear	Start fresh when you switch tasks (the cheapest fix for a confused session)

Claude Code compacts automatically near the limit, but details from early in a long conversation can get lost. Anything that must always apply belongs in CLAUDE.md, not in chat.

Sessions

Conversations are saved locally (under ~/.claude/projects/), so you can pick them up later:

claude -c                      # continue the latest session in this folder
claude -r                      # choose from a list of sessions
claude --resume <session-id>   # a specific one

Inside a session, /resume opens the picker, and /branch forks the conversation so you can try an alternative without losing the original. To work on two branches at once, run separate sessions in separate git worktrees.

Teach Claude your project: CLAUDE.md

Every session starts with an empty context. CLAUDE.md files are instructions loaded at the start of every session: your build commands, conventions, and the things Claude can’t work out from the code.

Where they live

Scope	Location	Shared with
Organisation	/etc/claude-code/CLAUDE.md (Linux), /Library/Application Support/ClaudeCode/CLAUDE.md (macOS)	Everyone on the machine
You, all projects	~/.claude/CLAUDE.md	Only you
Project	./CLAUDE.md or ./.claude/CLAUDE.md	Your team, via git
You, this project	./CLAUDE.local.md (add to .gitignore)	Only you

Files are combined, not overridden. Claude Code loads CLAUDE.md from the working directory and every parent folder, and loads files in subfolders when Claude works there. If a repo already has an AGENTS.md, Claude can read that too.

Create one

Run /init. Claude analyses the codebase and writes a starter CLAUDE.md with build and test commands and the conventions it found. Then trim it and add what it couldn’t discover. A good one is short and specific:

# Lone Elixir site

Astro 7 static site. Content is Markdown in src/content/entries/<section>/.

## Commands
- `npm run dev` – local preview at http://localhost:4321
- `npm run build` – must pass before every commit

## Conventions
- New entries need frontmatter: title, section, group, type, date, summary, tags
- No client-side frameworks; interactive behaviour goes in public/assets/site.js
- Never commit node_modules/ or dist/

## Gotchas
- The server deploys the `deploy` branch, which CI builds. Never edit it by hand.

Write instructions as you would for a capable new teammate. Vague lines (“write clean code”) cost context and change nothing. Contradictory lines make Claude pick one at random.

Imports

Pull in other files with @path:

See @README.md for the overview and @docs/git-workflow.md for branching rules.

# Personal preferences shared across worktrees
- @~/.claude/my-project-notes.md

Modular and path-scoped rules

For larger repos, split instructions into .claude/rules/*.md. A rule can be scoped to file paths, so it only loads when Claude touches matching files:

---
paths:
  - "src/api/**/*.ts"
---

# API rules
- Every endpoint validates input with zod
- Return errors as { error: { code, message } }

Personal rules for every project go in ~/.claude/rules/.

Auto memory

Alongside your CLAUDE.md, Claude keeps its own notes (MEMORY.md) from your corrections and preferences, and reloads them each session. CLAUDE.md is for rules you set; auto memory is for things Claude learned from working with you.

CLAUDE.md is guidance, not enforcement. To guarantee something never happens, use a permission rule (below) or a hook (part 3).

Settings and permission rules

Settings are JSON files at several levels:

File	Scope
~/.claude/settings.json	You, all projects
.claude/settings.json	Project, committed for the team
.claude/settings.local.json	You, this project (git-ignored)
Managed settings	Organisation policy, which can’t be overridden

More specific levels win: managed policy, then command-line flags, then local, then project, then user. For permissions, a deny at any level always wins over an allow.

A practical project .claude/settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git commit *)",
      "WebFetch(domain:docs.astro.build)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)"
    ]
  }
}

Rule syntax:

• Bash(npm run *): the space before * matters. Bash(ls *) matches ls -la but not lsof.
• Read(path) / Edit(path): gitignore-style patterns. A Read deny also blocks edits to that path.
• WebFetch(domain:example.com): per-domain web access.
• mcp__github__*: every tool from one MCP server (part 4).

Run /permissions to see and edit the active rules. When you answer “Yes, and don’t ask again” to a prompt, the rule is saved to .claude/settings.local.json.

Habits that pay off

• Be specific. “Fix the login bug where a wrong password shows a blank screen” beats “fix the bug”.
• Explore before editing. Ask Claude to read and explain the relevant code first.
• Give it a check. Tests, a type check or a build command it can run.
• One task per conversation. Use /clear between unrelated tasks.
• Commit often. Small commits make Claude’s work easy to review and revert.

Next

Part 3 makes Claude Code yours: custom skills (slash commands), subagents, hooks, plugins, and running it from scripts and CI.