Get the most out of
Claude Code

What is Claude Code

Claude Code takes a natural-language request, reads your project files, edits them and runs commands - all directly from the terminal, with no copy-pasting into a chat window. It doesn't pre-index your code; it reads only what it needs, on demand, so it works well at any project size.

When to use it - and when not

Commands

Most day-to-day work is managing context and sessions. These are the ones worth knowing first:

Keyboard shortcuts

Attaching files and images

There are three handy ways to give Claude a file or image to look at:

CLAUDE.md

Claude reads CLAUDE.md at the start of every session. It's where you put the project's architecture, code standards, run commands, and any rule you want Claude to follow. It's the big difference between Claude guessing and Claude knowing your project.

In an existing project you can run /init - Claude scans the code and generates a draft based on the conventions it detects. It's not mandatory: you can simply write the file by hand. Either way, review the result and fill in what Claude can't know on its own.

Where to put it

At the project root as CLAUDE.md (shared with your team), or at the user level (global) so it applies across all your projects.

# Project: [name]

## What this is
[one sentence: what the system does and who it's for]

## Stack
- language / framework + version
- database, main libraries

## How to run
- local:  [command]
- tests:  [command]
- build:  [command]

## Where things live
- main code:        [path]
- models / types:   [path]
- tests:            [path]

## House rules
- run tests after every change
- keep files under 300 lines, otherwise split
- don't change existing behavior without saying so explicitly

Custom commands & Skills

If you find yourself giving Claude the same instructions over and over, turn them into a permanent file. It's always a single markdown file - the main difference is whether you added a small header at the top (and which folder it lives in).

That header is called frontmatter: a few lines between --- and --- right at the start of the file. Without it - a command you run manually. With it - Claude reads the description and runs the skill on its own when it's relevant. Nothing beyond markdown is required.

A manual command (no header) is saved as .claude/commands/<name>.md. A Skill (with a frontmatter header) is saved at .claude/skills/<name>/SKILL.md. Either way you can save it at the project level (in the project's .claude folder) or at the user level (global, in ~/.claude) so it's available across all your projects. You can use $ARGUMENTS to receive input at invocation time.

Example: code audit (manual command, no header)

Audit $ARGUMENTS for problems.

Group the findings by severity:
- Correctness: wrong results or unhandled inputs
- Safety: anything that can crash or lose data
- Clarity: confusing names, dead code

Give the location of each finding and a one-line fix.
List only - do not change any code yet.

Example: documenting functions

Add short documentation to every public function in $ARGUMENTS.

For each one, note:
- What it does, in one sentence
- What each input expects
- What it returns or changes

Follow the file's existing style. Don't touch the logic.

Example: a Skill with automatic invocation (with a frontmatter header)

Note the lines between --- at the top of the file - that's the header. The description in it is what Claude reads to decide when to load the skill on its own.

---
name: naming-check
description: Reviews variable and function names for clarity. Use when the user asks to rename, clean up, or review naming.
---

When checking names:
1. Flag vague ones (data, temp, x, helper, doStuff)
2. Suggest a name that states what the thing is or does
3. Keep the project's existing casing convention
4. Names only - never change behavior

Workflows

The three pillars

The development cycle

Permissions

Claude Code uses a tiered permission system: read-only tools (like Read and Grep) need no approval; system commands and file edits do. Rules are checked in the order deny → ask → allow, and a block always wins. Most users can simply stay on Auto mode and not touch anything - this chapter is for those who want precise control.

Where to configure

Settings live in a settings.json file at two levels: project level as .claude/settings.json (shared with the team), and the user level (global) that applies to all your projects.

Permission modes

Example: minimal - auto-approve read-only

A safe starting point. Claude reads the code freely but asks before running commands or editing.

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob"
    ]
  }
}

Example: solo developer - trust most tools

For personal projects, minimum interruptions. Worth putting in your global settings.

{
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Read",
      "Edit",
      "Grep",
      "Glob",
      "WebFetch",
      "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)"
    ]
  }
}

Plugins & MCP

Plugins - a single package bundling skills, hooks and MCP servers together, easy to share and install. You enable and install them with the /plugin command.

MCP servers - connect Claude to external tools: browsers, databases and APIs.

Plugins

Run /plugin inside a session to open the plugin manager and see what's available, or install directly:

# UI design system
/plugin install frontend-design@claude-plugins-official

Choosing a model

Switch between models with /model. A simple rule of thumb:

Sub-agents

A sub-agent is a copy of Claude that gets its own task and runs in a separate context, sometimes in parallel with others. The main session divides the work, each agent focuses on its part and returns the result. The upside: broad, fast coverage without overloading a single conversation. The downside: each agent has its own cost and setup, so it's not always worth it.

FAQ