# Claude Code Workflows

Once the basics click, the gap between "it writes code" and "it saves me hours"
is all workflow. These are the features that close it.

Plan mode in action: approve a written plan once, then watch it run and commit. Illustrative session.

## Plan before you edit

For anything bigger than a one-liner, [use plan mode](/guides/break-big-tasks-into-steps). Claude reads and explores
but does not touch a file until you approve a written plan.

Enter it by pressing `Shift+Tab` until you reach plan mode, or start a request
with `/plan`:

> /plan add rate limiting to the public API

You get back a numbered plan. Now you steer it in plain English · "drop step 3",
"scope this to the auth routes only", "add a test for the limit". When the plan
is right, you approve once and Claude executes the whole thing. You review the
design instead of refereeing every edit.Approving a plan is the last gate before unsupervised edits, so skimming it and hitting accept is the mistake that bites: Claude then runs every step without pausing, and a vague line like "update the config" can rewrite more than you meant. Read each numbered step and pin down anything fuzzy ("which config file?") before you approve, not after.

Use plan mode for refactors, unfamiliar codebases, and anything where an
accidental change would be expensive.

## How does memory work in Claude Code?

Claude Code has two kinds of memory, and they serve different jobs.

- **CLAUDE.md** is what *you* write: conventions, commands, architecture, the
  "always do X" rules. Project `CLAUDE.md` is committed and shared with the
  team. A personal `~/.claude/CLAUDE.md` applies across all your projects, and
  `CLAUDE.local.md` (gitignored) holds per-project preferences just for you.
- **Auto memory** is what *Claude* writes as it works · build quirks, debugging
  patterns, things it learned about your repo. It loads automatically next time.

Run `/memory` any time to see exactly what is loaded and edit it, and read
[rules and memory files](/guides/rules-and-memory-files) for the full tour. For large
projects, split rules into `.claude/rules/*.md` files scoped by path, so your
frontend rules only load when Claude is in `src/components`:

```markdown
---
paths:
  - "src/components/**"
---
# Frontend rules
- Use the primitives in src/components/ before hand-rolling UI.
```

Scoped rules keep each session's context lean, which keeps it sharp.

## What is a subagent and when should I use one?

A subagent is a separate Claude instance with its own context window. It runs a
focused task and returns only the conclusion, so your main session never fills
up with file dumps.

> use a subagent to find everywhere we validate user input

That is perfect for sweeps across many files, independent parallel tasks, or
keeping noisy exploration out of your main thread. Open `/agents` to create
custom subagents with their own system prompts and tools, and see
[how agents fan out](/guides/how-agents-fan-out) for the strategy behind them.

## How do I create a custom skill?

When you keep pasting the same checklist or procedure, turn it into a skill. Drop
a markdown file at `.claude/skills//SKILL.md` and invoke it with
`/`:

```markdown
# Release checklist
1. Run the full test suite.
2. Bump the version.
3. Update the changelog.
4. Tag and push.
```

Skills are reusable knowledge. Reach for one whenever a workflow is worth a
shortcut.

## What are hooks and how do I use them?

Hooks run a deterministic shell command at lifecycle events · they do not need
the model to reason, so they always fire.A hook that exits non-zero is not silent: its error output gets fed back to Claude and can stall the session, so a flaky linter that fails on a warning will keep interrupting work. Make the command return zero unless you want to block the action, and set `async: true` for slow checks so they do not hold up the turn. Configure them in `.claude/settings.json`.
A classic is linting after every edit:

```json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [{ "type": "command", "command": "npx eslint src/", "async": true }]
      }
    ]
  }
}
```

Use hooks for enforcement (format, lint, block unsafe commands) and
notifications. Use CLAUDE.md and skills for anything that needs judgement.

## How do I review my code before pushing?

Before opening a pull request, run a review of your branch:

> /code-review

It reports likely bugs and simplifications across your commits and uncommitted
changes. To narrow the review to just what you have staged, see [review AI changes safely](/guides/review-ai-changes-safely). Useful flags:

- `--fix` applies the findings to your working tree
- `--comment` posts them as inline PR comments
- effort levels from `low` (few, high-confidence) to `max` (broad)

For cleanup only · reuse, simplification, style, no bug hunting · use
`/simplify`, which applies its fixes directly.

## Git and pull requests, conversationally

You rarely need raw git. Ask for the outcome:

> create a branch called feature/rate-limit, commit my work, and open a PR

Claude drives `git` and `gh` for you, writes a sensible commit message, and
links the session to the PR so you can resume it later with `claude --from-pr`.

## A few habits that compound

- Resume instead of restarting: `claude --continue` keeps your context.
- Use git worktrees (`claude --worktree feature-x`) to [run parallel work without
  edit collisions](/guides/isolate-parallel-agents-with-git-worktrees).
- Invoke skills explicitly when you know which one you want · it saves context.
- Set a default permission mode in `settings.json` once you trust a project.

Plan, remember, delegate, review. Stack those four and Claude Code stops feeling
like autocomplete and starts feeling like a teammate.