Claude Code in practice — a checklist · Resource

This is the version to keep open next to your terminal. Every step starts with a verb and can be checked — do it, then look at whether the result is what it should be. Work through it in order: first the things that can't break anything, then the habits used by people who get the most out of the tool.

The guiding rule in one sentence: don't hunt for magic prompts — give the tool context and a way to check its own work.

0. Before you start

Check what you're working with and what to expect before you type the first command.

Download and run Claude Code — don't wait for any setup or indexing step. Confirm the tool responds right after launch.
Stay in your current code editor. Claude Code lives in the terminal and works alongside what you already have — don't switch tools for it.
Expect an empty prompt line. That's a deliberate choice, not a gap — the tool doesn't push you into one fixed way of working.
Make sure you understand what it actually is: an agentic assistant that gets a goal and picks its own steps. It doesn't suggest one line at a time — it can write a whole function, a whole file, fix a whole bug.
Keep two reassurances in mind: your code never leaves your machine, and there's no "ingesting" the whole project on startup.

1. Start by asking about your own project

Before you change anything, ask first. This is the one piece of advice that outranks all the others.

Don't hand the tool a huge task on day one — that's the most common mistake, and it ends in disappointment. Start with a conversation.
Ask about a specific piece of code: "how is this used?", "why does it work this way?", "what did I actually ship this week?". Check that the answer reads like good documentation, not a list of search hits.
Ask for the project's history: "look through the history and explain where this odd function came from." Don't explain how to do it — the tool will dig through the Git repository itself and summarize the whole story.
Notice the boundary while you're at it: see what the tool handles on its own and what needs you steering it by hand.

2. Edit code — describe the goal, not the steps

Once you're comfortable asking questions, move on to changing code. The same logic applies.

Say what should exist — don't lay out the steps to get there. The tool has a small set of tools (editing files, running terminal commands, searching the project) and sequences them itself.
Don't write "use this now, then that." Describe the goal; leave the ordering (search first, then read, then change) to the tool.

3. Ask for a plan on any nontrivial task

This is the habit that pays off most for the least effort. Ask for a plan before the tool starts writing.

Say it plainly: "think this through, put together a plan, show it to me, and wait for my go-ahead before you write any code."
Don't look for a special mode or setting — just ask, and the tool knows what to do.
Read the plan and approve it before letting it move on. Five minutes approving a plan saves an hour fixing something that went the wrong way.

4. Give the tool a way to check its own work

If you remember one thing, make it this: when the tool has a way to check its own work, it drives that work to a far better state on its own.

Give it a way to see the result: a screenshot of the finished page, a test suite, or a preview — anything that lets it judge for itself whether it got it right.
Let it refine the result. Check that after two or three passes the outcome lands almost exactly right — the tool compares the result to the goal, fixes it, and checks again.
Use the same trick in every domain: give it any way at all to see the outcome of its own work. That's the feedback loop.

5. Give it context — starting with the simplest layer

The more the tool knows about your project, the better its decisions. It can't guess your context — you have to supply it. Start with the simplest option.

Set up a CLAUDE.md file — short notes the tool reads automatically at the start of every conversation. Write what you'd tell someone new joining the project: the most common commands, a few key files, important decisions.
Keep this file short. If it grows too large, it starts taking up space and stops helping.
Decide whether you share it with the team (write it once, everyone benefits) or keep a private, local version just for yourself.
Save repeated actions as slash commands (triggered with /). If you repeat something every week, write it once and run it with one command. These, too, can be shared with the team.
Connect the tools you already use — your own terminal programs, or the MCP standard (a shared protocol that lets Claude Code talk to external tools: a ticketing system, a database, anything). Tell it about them and show it how to use them, e.g. "use this program, check its own instructions yourself."
At a larger scale, layer context and rules: project-level (in the repository, shared), global across all your projects, and company-wide.
At the company layer, pre-approve safe commands (so no one clicks through the same prompt every time) and lock down dangerous ones so no one can bypass them.
If you don't know where to start, start with shared project context. Write it once, share it with the whole team — one person does a bit of work, everyone benefits.

6. Add useful moves and parallel work

A handful of small things for everyday use — reach for these once you're comfortable.

Turn on auto-accept mode once you see the tool is on the right track (fixing tests in a loop, for example). Terminal commands still need your approval, and everything can be undone.
Use the # character to make it remember something. If the tool isn't doing something your way, type # and say what's wrong — it adds this to its notes for next time.
Press Escape to interrupt safely at any point. Nothing breaks, the session isn't hurt — you interrupt, say what to change, and keep going.
Resume a session later instead of starting from zero. Come back to the same conversation and continue.
Once you're comfortable, consider running several sessions at once — separate copies of the project or working Git branches, so each session works in isolation. This isn't a required step, more a direction to try.
Keep in mind that Claude Code can also be driven from scripts — you feed in a command, the tool hands back a finished result, and you plug that into a larger automated flow. Don't reach for this on day one, but know the path exists.

Watch out for

The traps that most often derail a first attempt.

A huge task on day one. Throwing a giant instruction at the tool with no plan sometimes works out, and sometimes produces something entirely different from what you wanted — and the frustration starts there. Questions first, then a plan.
Skipping the plan on a nontrivial task. Five minutes approving a plan saves an hour fixing it. Don't let the tool start writing before it shows you what it intends to do.
No way to self-check. Without a screenshot, a test, or a preview, the tool has no way to judge its own work and stalls at "not bad" instead of reaching "almost exactly right."
A CLAUDE.md file that's too long. Once the notes grow too large, they start taking up space and stop helping. Keep it short.
Trying to make it guess your context. History, decisions, and the reasons "why we do it this way here" — the tool can't guess these; you have to supply them.

The smallest move for today: open your project and ask one question about something you've never fully understood. That's enough to get started.