Claude Code in action

Claude Code installed is not the same as Claude Code useful. The difference is almost entirely in how you feed it context and how you structure the conversation. This lesson is the short reference for the commands and workflows that turn a terminal chatbot into a productive peer engineer — /init, CLAUDE.md, the context-plan-implement loop, and the test-driven variant that produces the most robust output.

Start with /init

The first thing you should do in a new project is run:

/init

/init tells Claude Code to scan your entire codebase and build a scoped memory file called CLAUDE.md that becomes part of its context on every future call. The scan covers:

• Project structure and directory layout
• Dependencies and build tools
• Coding style and patterns
• Architecture and key modules
• How to run tests and builds

The resulting CLAUDE.md is a summary of everything Claude needs to know about your project, and it's automatically included as context in every subsequent turn. You never have to explain "oh, we use Pytest" or "the entry point is in src/main.py" again — the memory file carries that information.

The three scopes of CLAUDE.md

Memory files come in three flavours:

• Project CLAUDE.md — lives at the project root, checked into git, shared between everyone working on the codebase. Good for "this is how we build, test, and deploy."
• Local CLAUDE.md — your personal notes, not checked in. Good for "I'm debugging this particular branch, focus on these files."
• User CLAUDE.md — lives in your home directory, applies to every project you open. Good for "always use descriptive variable names" or "prefer explicit types over inference" — preferences that follow you everywhere.

Claude Code merges all three scopes into its context. Project memory is the shared source of truth; local memory is scratch space; user memory is your personal style.

Quick-adding to memory with #

You don't have to hand-edit CLAUDE.md to add notes. Type # at the start of a message and Claude Code prompts you to add the following content to your memory file:

# Always use descriptive variable names
# Prefer pure functions over methods with side effects
# Tests go in tests/ with a matching test_*.py name

Claude asks which scope (project, local, or user) and appends the note to the right file. Over time the memory accumulates the idioms and conventions of your project without any explicit writing work.

The context-plan-implement workflow

Here's the single most important habit for getting good output from Claude Code.

Don't ask Claude to write code immediately. Instead, work through three steps:

Step 1 — Feed context

Before asking Claude to build something, identify the files in your codebase that are relevant — existing features that look similar, modules you're extending, test files that show how the code is exercised. Ask Claude to read those files first:

> Read src/math.py and src/document.py

Claude reads the files, and from that point on those files are part of the conversation context. Claude now knows the actual patterns your code uses, the real names of functions, the style conventions you follow.

Skipping this step is the single most common reason Claude Code produces generic or off-style code. Without context, it's guessing at your patterns.

Step 2 — Ask for a plan (not code)

Instead of jumping to implementation, ask Claude to think through the problem and propose a plan, explicitly telling it not to write any code yet:

> Plan how to implement a document_path_to_markdown tool.
> Do not write any code yet. Just outline the steps.

Claude responds with a structured plan — what function to write, where it goes, what arguments it takes, what edge cases to handle, what tests to add. Read the plan carefully. This is where you catch mistakes cheaply — if the plan is wrong, you correct it in conversation before any code gets written. Corrections to a plan cost seconds; corrections to a half-written implementation cost minutes and sometimes confuse the model.

Step 3 — Ask for the implementation

Once the plan looks right, tell Claude to execute:

> Implement the plan.

Claude writes the code based on the context from step 1 and the plan from step 2. Because both the context and the plan are now in the conversation, the output is substantially more likely to match your codebase's conventions and handle the cases you care about.

This three-step pattern is the default workflow for any non-trivial task in Claude Code. It's slower per iteration than "just write the code," but the iterations are higher-quality and you spend less total time going back to fix things.

Test-driven variant

For critical code where you want to pin down correctness, use a test-driven variant:

1. Feed context — same as before.
2. Ask Claude to brainstorm test cases for the feature: "What tests would validate this? List the edge cases."
3. Pick the most relevant tests and ask Claude to implement them. You now have failing tests that describe what success looks like.
4. Ask Claude to write code that makes the tests pass. Claude iterates on the implementation, runs the tests, and adjusts until they're green.

The advantage: Claude has explicit, mechanical success criteria to work toward. Instead of "make this look right," the goal becomes "make this specific test pass." The model is noticeably more reliable when the target is machine-checkable.

A concrete example

Suppose you want to add a document-conversion tool to an existing project. The full workflow looks like:

> Read src/math.py and src/document.py
(Claude reads the files)

> Plan how to implement a document_path_to_markdown tool:
> validate the file exists, determine type from extension, read the
> binary data, reuse the existing binary_document_to_markdown function,
> and return a markdown string. Do not write code yet.
(Claude proposes a 4-step plan)

> The plan looks good but add error handling for unsupported
> extensions, raising a ValueError. Then implement.
(Claude writes the code, updates the files, writes tests, runs
 the test suite, and reports that everything passes.)

The plan step was where the requirement about unsupported-extension errors got added cheaply. If you'd jumped straight to "implement this feature," you'd have discovered the gap later, probably in a code review. Catching it in the plan costs one sentence.

Essential commands

Three commands you'll use constantly:

| Command | Purpose | |---|---| | /init | Scan the codebase and generate or update CLAUDE.md | | /clear | Clear the conversation history and reset context (useful between unrelated tasks) | | # | Prefix a note to be appended to a CLAUDE.md memory file |

/clear is the one most people forget to use. When you finish a task and move to an unrelated one, the accumulated context from the previous task is noise — it makes Claude slightly slower, occasionally confuses the model about what you're working on now, and costs tokens. Clear it. Treat /clear as the "open a new tab" gesture.

Claude Code as a full collaborator

Claude Code isn't limited to writing new code. It can also:

• Stage and commit changes to git with generated commit messages
• Run tests and iterate until they pass
• Manage dependencies — add packages, update versions, check for conflicts
• Debug failing CI by reading logs and fixing the root cause
• Refactor across multiple files consistently
• Write documentation by reading the code and explaining it

The recurring theme: the more context and structure you provide, the more effectively Claude can help. Treating Claude Code as a rubber duck with superpowers — "here's what I'm thinking, what do you notice?" — often produces better outcomes than "do this for me."

The next lesson covers extending Claude Code with MCP servers so it can reach beyond files and terminal into your issue tracker, your monitoring, your design system, and anywhere else your team's work actually happens.