Claude Code Tutorial: Ship One Verified Change

Mental model

Use the shipping loop, not a chat loop

Claude Code is useful because it can inspect files, run commands, edit code, and iterate from command output. Treat that as a shipping loop: context, action, verification, review. A prompt that skips any of those phases usually creates work you still have to debug by hand.

The first session should be boring on purpose. Pick a low-risk issue, tell Claude where to start, give it the command that proves success, and require a concise change summary. This teaches the agent the repository while keeping the blast radius small.

Primary-source anchor: Anthropic frames verification as the difference between watching a session and giving Claude a pass/fail loop it can close itself.

Install, authenticate, and confirm the surface

Use the official install path for your operating system and confirm authentication before you start making repository changes. The CLI supports interactive sessions, direct prompts, piped input, resumes, authentication status checks, MCP configuration, and background-agent commands.

If you are evaluating Claude Code for a team, record the exact install method, authentication method, default shell, package manager, and test command in the repository instructions. Otherwise every future session starts by rediscovering the same facts.

claude auth status
claude
claude -p "Explain the top-level structure of this repository"
cat failing-test.log | claude -p "Summarize the failure and likely files"

Primary-source anchor: the CLI reference lists interactive sessions, non-interactive prompts, piped input, resumes, auth commands, MCP commands, and agent commands as first-class interfaces.

Choose a first task Claude can verify

Good first tasks have narrow file ownership and a clear signal: fix one failing test, update one doc page, add one validation rule, or reproduce one small bug. Bad first tasks ask Claude to redesign architecture before it has learned the repo.

Tell Claude what must stay out of scope. If the task is a bug fix, say whether it may refactor adjacent code. If the task is UI work, tell it how to verify the visual result. If the task touches data or permissions, require a plan first.

• Start from a clean or intentionally isolated worktree.
• Name the exact command or artifact that proves the result.
• Require Claude to inspect existing patterns before editing.
• Ask for a final diff summary and the verification output.
• Review the diff yourself before merging or deploying.

Use prompts that contain context, constraints, and evidence

A strong first prompt is plain engineering direction. It names the symptom, the likely area, the desired behavior, and the verification command. It also tells Claude how to report back.

Do not over-specify every file read or command. Claude Code is designed to gather context and choose tools. Give it the destination and guardrails; let it discover implementation details from the codebase.

The checkout form rejects valid postal codes in Canada.
Investigate src/checkout and existing validation tests before editing.
Fix the narrow bug, add or update focused tests, and run npm test -- checkout.
Stop only after showing the diff summary and the test output.

End the session like a code review

Claude can explain what changed, but it is not the reviewer of record. Ask for the changed files, verification command, result, known residual risk, and anything intentionally left out. Then inspect the diff the same way you would inspect a teammate's PR.

If the result took more than a few corrective turns, consider starting a fresh session with the learned constraints. Long, messy context can become less reliable than a short prompt that captures the actual requirement.

Primary-source anchor: Anthropic describes Claude Code as an agentic loop that gathers context, takes action, verifies results, and remains steerable by the human operator.