Your first 30 minutes in Claude Code: read, explain, and commit without breaking anything

First contact with Claude Code stalls for one plain reason: fear of approving the wrong change in your real project. You open the terminal, think about asking something, and freeze on what it might alter. This walkthrough fixes that with a short, shielded session.

You will practice on a separate branch, read before editing, make a minimal change, review the diff with tests, and close with a commit. If you still need to install or sign in with the right account, start with the overview map at Claude Code from zero. The read, explain, change, review, commit cycle follows the walkthrough published Apr 8, 2026 in the getting-started guide and the hands-on loop from Apr 27, 2026 in the complete getting-started guide.

No edits before confirming git and cutting a branch for practice. The practice branch isolates every suggestion from your real work and leaves the diff as proof of what changed. That care opens the Apr 8, 2026 walkthrough in the getting-started guide and the Apr 27, 2026 loop in the complete getting-started guide.

Enter the project folder before opening the agent. Opening in the right place bounds what commands can reach and keeps a vague instruction away from files outside the scope. If install duty still waits, check the walkthrough at how to install on Windows, Mac, and Linux and come back with claude --version and claude doctor answering.

Run these two commands to set up practice:

git status
git checkout -b practice-30min

The first shows pending changes you should shelve before training. The second creates the practice-30min branch and switches to it. The rule runs straight: if git status shows dirt, clean or stash it before requesting any edit.

Reading before editing works as a safety latch, not a slowdown. Explanations change no files and reveal on the spot whether the agent grasped the right context.

A good request carries three short parts: where, what, and how to check. Where points at the folder or file. What describes the change in one sentence. How to check names the read or test that proves it worked. That shape cuts round trips because it hands over the context the agent would otherwise ask back for.

Use that frame in every block below. It turns the read-and-explain-first recommendation from the getting-started guide, Apr 8, 2026, into a repeatable habit.

Copy these two reading templates to start:

List this folder's structure without changing anything.

Explain what the getUserById function does in this file, without changing anything.

The protection sits at the end of each sentence: without changing anything. That explicit instruction holds the agent in reading mode and asks only for explanation. Once the explanation cites the right file and function, the context is ready for one small change.

For changes, use this template:

In this file, rename the total variable to totalUsers and show the diff before finishing.

It carries where (in this file), what (rename the variable), and how to check (show the diff). Requests shaped like that produce short diffs, which review line by line with ease.

The split below adds to exactly 30 minutes and ends with a commit done. It organizes the short chores from the Apr 8, 2026 walkthrough in the getting-started guide and the first-commit loop from the Apr 27, 2026 complete getting-started guide. Treat the times as rhythm guidance, not pressure.

Block 1, 5 minutes: read the layout, change nothing

Reading first builds the map that prevents blind requests. Ask for the folder list and the job of one central file, always with the without-changing-anything latch. The block's goal is answering out loud: where the project's entrances sit and which file owns which part.

If the answer cites files that do not exist, stop and fix the path before moving on. That plain context mistake explains most misplaced suggestions. Five good minutes here save fifteen in review.

Block 2, 5 minutes: ask for an explanation before any edit

An explanation confirms the agent read the right code. Ask what the getUserById function does, which inputs it takes, and what it returns, still changing nothing. The answer should cite real file and variable names from your project.

Advance only once you can repeat the explanation in your own words. If you cannot explain it, authorize no change. That short pause is the heart of the Apr 8, 2026 walkthrough in the getting-started guide: understand before altering.

Block 3, 7 minutes: make one tiny, visible change

A small change makes a short diff and a fast test. Pick one of two chores for the first drill: rename a confusing variable or write a plain unit test for getUserById. Both show up as safe first chores in the April 2026 walkthroughs.

For the rename, use the previous section's template and confirm only the name moved. For the test, use this short prompt:

Write a simple unit test for getUserById with one valid case, without changing the function.

If the agent proposes touching three files at once, ask for a redo in one. The drill's rule is one change at a time, with a readable on-screen diff.

Block 4, 6 minutes: review the diff and run the test

Review is where practice turns into trust. Run the diff and read every added or removed line as if you typed it. Ask of each stretch: do I understand what this line does and why it exists now.

git diff
npm test

git diff shows what moved on the practice branch. npm test runs the project suite and proves the change broke nothing basic. On a failing test, revert the file and ask again in a smaller slice, still on the same branch. No mistake here costs much because nothing left the training branch.

Block 5, 7 minutes: land the first commit with a clear message

A commit closes the loop and builds history you can undo. Check status, stage only the drill's files, and write a message that says what moved and why. That plain-commit close follows the Apr 27, 2026 loop in the complete getting-started guide.

git status
git add src/users.js test/users.test.js
git commit -m "Rename total to totalUsers for clearer reading"

Swap in your drill's real paths and keep the message shape: verb first, what moved, short why. In the final minutes, jot two lines on what worked in the request and what you will ask differently next time.

One-shot mode runs a single request and exits, never opening the interactive chat. It serves closed questions with short answers, like summarizing history or explaining an error with context ready. That use sits in the Apr 27, 2026 complete getting-started guide.

Try it now on the practice branch with this literal example:

claude -p "Summarize the last 5 commits in this repo as short bullets"

Stay in normal chat when the chore edits files, because it holds context across questions, proposals, and tweaks. Use claude -p when you need only reading or a summary with everything checkable on screen. That split avoids opening a long session for a doubt that fits one line.

For help and resuming, keep three base commands from the official quickstart guide. /help shows in-session help. The -c and -r flags resume or continue an earlier conversation without repeating all context. If the current session wedges, restart clean rather than dragging confusion along.

The three mistakes below repeat because they pose as shortcuts. Each carries a plain exit back to the practice branch with nothing lost. The list mirrors the 3 stumbles in the Apr 27, 2026 complete getting-started guide.

1. Authorizing everything to move faster

Freeing every command removes the pause guarding sensitive files and destructive commands. In drills, keep approval on and answer case by case. Authorize reading and explaining freely, and read every write or run request with care.

If you already unlocked everything, return to careful mode and review the permission list before the next request. The full story on that lock lives in the cluster's next guide: CLAUDE.md and safe permissions.

2. Letting the conversation grow heavy without clearing context

Long chats pile up old attempts and the agent starts blending requests. The tells are vague answers, wrong files, and repeats of already-fixed points. The fix uses two base commands from the official quickstart guide.

Run /compact to summarize a conversation that still holds useful points. Run /clear to wipe everything and restart once context is lost. Then repeat the short request with where, what, and how to check, still on the practice branch.

3. Starting with no useful first line in CLAUDE.md

CLAUDE.md holds the project's instructions for the agent, and the first useful line says how to validate the work. Without the test command there, every answer suggests a different way to check. With it, the agent already proposes npm test or your project's right command.

For this drill, one line with the test command plus one line with what never happens without permission is enough. Full structure examples and permissions live in the next guide: CLAUDE.md and safe permissions.

Do I need git for the first 30 minutes?

You need the basics: status for pending work, checkout -b for the practice branch, diff for review, commit for the record. That minimum set conditions the cycle in the Apr 8, 2026 walkthrough in the getting-started guide and the Apr 27, 2026 one in the complete getting-started guide. Without it there is no comparing, no reverting, no proving what moved.

Which change should I make first?

Make the smallest visible change: rename a confusing variable or write a plain unit test for getUserById. Both produce a short diff and a fast test, which eases the block-4 review. Skip building new features in the first drill, because they grow long, hard-to-check diffs.

When should I use claude -p instead of normal chat?

Use claude -p for closed questions with short answers, like the example of summarizing the last 5 commits against git log. That one-shot pattern is in the Apr 27, 2026 complete getting-started guide. Stay in normal chat for edits, because it keeps context across proposal, tweak, and review.

What if the conversation turns confusing?

Run /compact to summarize and hold the thread, or /clear to wipe and restart from zero, per the command base in the official quickstart guide. Then repeat the short request with where, what, and how to check, still on the practice-30min branch. If the diff already runs big and tangled, drop the branch and cut another to repeat the drill.

You closed the full loop once: read, asked for an explanation, changed little, reviewed the diff with tests, committed with a clear message. Repeat the same script with a slightly bigger chore, still on a training branch. The second round aims at better asking, not more output.

The second round matters more than the first. The first teaches the buttons. The second, with a slightly bigger chore, teaches asking. And asking well is the skill that transfers to everything else.

Once the 30-minute flow feels comfortable, lock safety before speeding up. Next is a short CLAUDE.md plus careful-mode permissions: CLAUDE.md and safe permissions.

• getting-started guide
• complete getting-started guide
• official quickstart guide