Claude Code fundamentals

I've been exploring Claude Code for a few months now, using it alongside my existing CI/CD workflows with GitHub and Buildkite. What started as curiosity and trying to keep up with this rapid change in software tooling, has become a core part of how I approach development tasks. This post is documenting what I've learned and a repository of useful context and commands I can refer back to.

Context is everything

The biggest mental shift with Claude Code is understanding that it's only as effective as the context you give it. Unlike a traditional IDE, Claude doesn't automatically understand your codebase, you need to help it along. Thankfully, Claude has a really easy and great way to start with the /init command, which will initialise your Claude Code project.

The claude.md file

This is where it all begins. When you initialise a Claude Code project, you create a claude.md file. claude.md has two main purposes: helping Claude understand your codebase, and giving it general guidance about how you want it to behave.

The contents get sent with every request, so think of it as persistent context. There are three common locations of that claude can make use of in your local filesystem:

• Project level (committed, shared with your team)
• Local level (personal, not committed)
• Machine level (global for all projects)

You can use the # command to enter "memory mode" and edit these files directly. If Claude keeps adding too many comments to your code, update the file. If it keeps suggesting patterns your team doesn't use, tell it once in claude.md and it'll remember.

Planning vs thinking modes

These handle different types of complexity, and understanding when to use each will save you tokens and get better results.

Planning mode works best for tasks that require broad understanding of your codebase, multi-step implementations, changes affecting multiple files, or anything where Claude needs to map out dependencies first. It will create a big to-do list, that you can provide feedback to ensure you and claude are on the right path from the beginning.

Thinking mode is for depth rather than breadth. Complex logic problems, debugging difficult issues, algorithmic challenges. Use this when the problem is narrow but deep. There are many levels of thinking budget that you can apply:

These specific phrases are mapped directly to increasing levels of thinking budget in the system: "think" < "think hard" < "think harder" < "ultrathink." Each level allocates progressively more thinking budget for Claude to use.

You can combine both planning and thinking for tasks that need breadth and depth, but they will use much more tokens.

Managing context during long sessions

Long conversations accumulate noise. Claude might spend time debugging an error, and that back-and-forth becomes irrelevant once the issue is resolved. There are a few ways to keep things focused:

Interrupting and rewinding

Press Escape to interrupt Claude. Press it twice to see all messages you've sent, allowing you to jump back to an earlier point. This lets you maintain valuable context while removing distracting conversation history.

The compact command

/compact summarises your conversation history while preserving key information Claude has learned. Use this when Claude has gained valuable knowledge about your project and you want to carry that forward to related tasks without the noise.

The clear command

/clear removes everything. Use this when switching to a completely different task where the previous context would just confuse things.

Custom commands

You can create your own slash commands by setting up a folder structure:

1. Find the .claude folder in your project
2. Create a commands directory inside it
3. Add a markdown file with your command name (e.g., audit.md creates /audit)

The filename becomes the command. We've created a few for common tasks - running our standard code review checklist, generating consistent PR descriptions, that sort of thing.

MCP servers

Model Context Protocol servers extend what Claude can do. The Playwright MCP server is a good example. It gives Claude browser automation capabilities.

To install Playwright:

claude mcp add playwright npx @playwright/mcp@latest

This names the server "playwright" and provides the command to start it locally.

Managing permissions

Claude will ask permission each time you use MCP tools. To pre-approve, edit .claude/settings.local.json:

{
  "permissions": {
    "allow": ["mcp__playwright"],
    "deny": []
  }
}

Note the double underscores in mcp__playwright.

Hooks

Hooks let you run custom logic at different points in Claude's workflow. The main ones are PreToolUse and PostToolUse, but there are others:

• Notification – runs when Claude sends a notification
• Stop – runs when Claude finishes responding
• SubagentStop – runs when a subagent (shown as "Task" in the UI) finishes
• PreCompact – runs before a compact operation
• UserPromptSubmit – runs when you submit a prompt, before Claude processes it
• SessionStart / SessionEnd – runs at session boundaries

One practical use: hooking into PostToolUse to run type checking automatically. You can ask Claude to list the tools it has access to if you're curious what's available to watch for.

What's worked for me

The combination of a well-maintained claude.md file and regular use of /compact has made the biggest difference. Claude learns about your project as you work, and keeping that knowledge while shedding irrelevant conversation history is the key to productive longer sessions.

The custom commands have been useful for repetitive tasks, though I'm still experimenting with what's worth formalising versus just asking Claude directly each time.

MCP servers open up interesting possibilities for integrating with external systems. I've been looking at the GitHub MCP server for automated PR reviews, the ability to have Claude identify security issues automatically is appealing given how easy it is to miss things in busy periods. Beyond pure software workflow and lifecycle integration, MCP integrations help with a bunch of recipe shortcuts I'm thinking about in my Engineering Director and management responsibilities. Pulling down interesting stats and trends that help me prepare and shortcut tasks that can be quite manual. I'll experiment further with this and share how I am using these tools.

These fundamentals aren't complicated, but they compound. Understanding the context system, using the right mode for the problem. That's where the value is.