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 before you edit

For anything bigger than a one-liner, use plan mode. 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.Common gotchaApproving 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 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:

---
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 windowThe running memory of everything Claude can see at once, from your prompts to the files it has read. 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 promptsThe standing instructions that define an agent's role and behaviour before any of your messages and tools, and see 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/<name>/SKILL.md and invoke it with /<name>:

# 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 eventsFixed moments in a session such as before a tool runs or after an edit, where an action can be triggered automatically · they do not need the model to reason, so they always fire.Common gotchaA 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:

{
  "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. Useful flags:

• --fix applies the findings to your working treeThe files in your project as they currently sit on disk, including edits you have not committed yet
• --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 worktreesExtra working copies of one repository checked out to separate folders, so each can sit on a different branch at the same time (claude --worktree feature-x) to run parallel work without edit collisions.
• Invoke skills explicitly when you know which one you want · it saves context.
• Set a default permission modeThe setting that controls how much Claude can do on its own before stopping to ask you for approval 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.