How to use Claude Code: a hands-on tutorial for daily work

This tutorial starts where installation ends. If you have not installed the agent yet, follow How to install Claude Code, and if you want the big picture of what it is and what it costs, read the Claude Code overview. What follows is how to work with it day to day: the controls you touch every session, the files that make it better over time, and a full worked example. Everything here reflects Anthropic's Claude Code docs as of October 2026.

Your first session

Start the agent from the root of a repository:

cd ~/projects/my-repo
claude

Start with questions rather than code: "give me an overview of this codebase", "how is authentication handled?". You learn the repo and see how Claude navigates it at the same time.

Reference files with @ (@src/utils/auth.js) instead of describing where code lives, and paste screenshots of errors or mockups straight into the prompt. To pick a session back up later, claude --continue resumes the most recent conversation in that directory and claude --resume shows a list.

Permission modes

A permission mode decides what Claude may do without asking. Press Shift+Tab to cycle through them during a session; the status bar shows the active one.

In current versions, auto mode is the starting mode for interactive terminal and VS Code sessions, provided you use a supported model and your organization has not turned it off. To approve every step yourself, start with claude --permission-mode manual.

Modes set the baseline. On top of them, /permissions manages allow, ask and deny rules. Deny rules apply in every mode, so this is the place to block things like pushing to main:

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(npm run lint)"],
    "deny": ["Bash(git push origin main)"]
  }
}

That block goes in .claude/settings.json and is shared with the team through git.

Plan mode: explore, plan, then code

For anything that touches several files, separate thinking from typing. Anthropic's recommended loop has four steps:

1. Explore in plan mode (Shift+Tab until plan mode on, or /plan in front of one prompt). Claude reads and answers without editing.
2. Plan. Ask what needs to change and for a step-by-step plan. Press Ctrl+G to open the plan in your editor and fix it directly.
3. Implement. Approve the plan; the session leaves plan mode and Claude starts editing, checking its work against the plan.
4. Commit. Ask for a descriptive commit and a pull request.

Skip the plan when you could describe the diff in one sentence.

CLAUDE.md and /init

Every session starts with an empty context window. CLAUDE.md is how knowledge survives between sessions: Claude loads it at the start of every conversation.

Run /init once per repository. It analyzes the codebase and drafts a CLAUDE.md with build commands, test instructions and conventions it finds. If one already exists, it suggests improvements instead of overwriting. Then edit by hand. Keep commands Claude cannot guess, style rules that differ from defaults, PR conventions and gotchas. Leave out anything Claude can learn by reading the code, and keep each file under about 200 lines. A bloated CLAUDE.md gets followed less, not more. Where the files live:

/memory opens these files for editing, and @path/to/file inside a CLAUDE.md imports another file.

The slash commands you will actually use

Type / to see everything. These are the ones that come up daily:

Your own commands are now skills (more on that below): .claude/commands/deploy.md still works and creates /deploy, exactly like .claude/skills/deploy/SKILL.md.

Managing context

The context window is the resource that matters most. Every file read and every command output lands in it, and quality drops as it fills. The habits that keep sessions sharp:

• /clear between unrelated tasks. Mixing three topics in one session is the most common failure.
• Correct early. Esc stops Claude mid-action with context intact. After two failed corrections, /clear and write a better prompt.
• /compact Focus on the API changes when you want to keep going but trim history.
• Rewind instead of arguing. Checkpoints are taken on every prompt, so you can let Claude try something risky and roll back. They only track edits made through Claude's own file tools, not Bash, so git remains your real safety net.

Subagents

A subagent runs in its own context window and reports back a summary, so exploration does not fill your main session. Built-in ones include Explore (read-only search) and Plan. The simplest use is to ask: "use a subagent to investigate how our auth system handles token refresh".

Custom subagents are Markdown files in .claude/agents/ (project) or ~/.claude/agents/ (personal). Only name and description are required in the frontmatter; the body is the agent's instructions:

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---

Hooks

CLAUDE.md is advice. A hook is a guarantee: a shell command Claude Code runs at a fixed point in its lifecycle, such as PreToolUse, PostToolUse, Notification or Stop. This example from Anthropic's docs runs Prettier on every file Claude edits:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Put it in .claude/settings.json and check it with /hooks. If Claude keeps breaking a rule in CLAUDE.md, turn it into a hook.

MCP and skills in brief

MCP servers connect Claude Code to external systems such as issue trackers, databases and design tools:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Then run /mcp inside a session to log in. The full walkthrough is in adding an MCP server to Claude Code.

Skills are folders with a SKILL.md in .claude/skills/<name>/ (or ~/.claude/skills/ for personal ones). Claude loads one automatically when its description matches the task, or you run it as /name. Add disable-model-invocation: true for workflows with side effects, like deploys, that should only run when you type the command. See Claude skills explained.

Worked example: from bug report to pull request

A realistic flow for a bug report that says login fails after a session timeout:

1. Start clean. /clear, or a new session. In plan mode, prompt: "users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. explain the likely cause".
2. Reproduce first. "Write a failing test that reproduces the issue. Run it and show me the output." A failing test is the check Claude will iterate against.
3. Plan and approve. Ask for a minimal fix plan, adjust it with Ctrl+G if needed, approve.
4. Fix and verify. "Implement the fix, run the auth tests and the linter, fix any failures. Address the root cause, do not suppress the error." Ask Claude to show the test output rather than just claim success.
5. Review. Run /code-review so a fresh subagent looks at the diff without the reasoning that produced it.
6. Ship. "Commit with a descriptive message and open a PR." With gh installed and authenticated, Claude creates the PR and links the session to it; claude --from-pr <number> finds that session again later.

The key move is step 2: give Claude a check it can run, and it closes the loop itself instead of waiting for you to spot mistakes.

Tips that actually help

• Be specific. Name files, the scenario and what "done" looks like. "Add tests for foo.py" is weaker than "write a test for foo.py covering the logged-out case, avoid mocks".
• Point to existing patterns in the repo rather than describing them.
• Run parallel work in worktrees with claude --worktree feature-auth so edits do not collide.
• Name sessions with /rename so /resume stays useful.

Rolling it out to a team

For a team, the open questions are where traffic goes, which MCP servers are allowed and who can see what was done. Claude Code can run against an LLM gateway instead of Anthropic directly, which puts model access, MCP policy and logging in one place. Walma AI Hub is that gateway, running in the customer's own Azure tenant in an EU region; see the AI Hub or the MCP gateway guide for how the controls fit together.