Direct answer
Design your first Claude Code session as a small, reversible verification loop rather than a large, vague development request.
What this guide helps you solve
Help new users establish an effective interaction rhythm and reliable acceptance habits with Claude Code.
Choose the first task with clear boundaries
The first task should fit within a small set of files and have a clear verification signal, such as fixing a bug with reproduction steps, adding tests for an existing function, or updating one section of documentation. Do not use "optimize the entire project" as a test of the tool's capabilities.
Start a session at the project root and inspect the Git worktree first. Claude Code can read files, edit them, and run commands, but it must still protect the user's existing uncommitted changes.
cd /path/to/project
git status --short
claude
Let Claude explain the project before editing
First ask about the entry point, dependencies, test workflow, and existing patterns related to the task. Claude Code reads files on demand, so there is no need to paste the entire repository into the prompt.
Ask it to cite specific files and functions and state any uncertainties. This lets you correct misunderstandings before changes begin and limits the context consumed by unbounded exploration.
先不要修改文件。请定位这个项目的入口、测试命令和错误处理模式，
只阅读与用户登录流程有关的文件，并用文件路径说明结论。For complex changes, enter Plan mode first
When a task involves multiple files, API decisions, or unfamiliar modules, use Plan mode to separate exploration from editing. The plan should list the files to modify, data flows, risks, tests, and explicit exclusions.
For a contained task such as fixing a typo or adding one log statement, planning may cost more than it saves. Match the amount of planning to the risk.
- 01ExploreRead the relevant implementation and tests in Plan mode without writing files.
- 02PlanList the changes, boundaries, and acceptance commands, then ask the user to confirm.
- 03ImplementExit Plan mode and edit according to the approved plan.
- 04VerifyRun tests, builds, or visual checks and report the evidence.
Write the acceptance conditions into the same prompt
Claude may stop when the work "looks done." Provide reproduction steps, edge cases, and verification commands together so it can implement the change, run checks, and continue fixing failures in the same turn.
Acceptance criteria should be observable: tests pass, the build exits with code zero, the endpoint returns the expected status, or critical differences between a screenshot and its reference are eliminated.
修复会话过期后登录失败的问题。先写一个能复现问题的测试，
再修改 token refresh 流程。只改 auth 模块，运行该模块测试，
最后列出修改文件、测试命令和结果；不要通过跳过断言掩盖失败。Review the diff and scope before submission
After the task is complete, inspect the Git diff before requesting a commit. Confirm that existing uncommitted changes were not overwritten, no unrelated formatting was introduced, and no keys or build artifacts were generated.
Ask Claude to summarize the diff, then use a fresh context or subagent to check only for correctness, regressions, and omissions. Independent reviewers should not propose requirement-irrelevant refactors merely to produce "findings."
git status --short
git diff --check
git diff
Stop early and roll back when you deviate
When the work heads in the wrong direction, press Esc to interrupt and add specific constraints. If two consecutive corrections still fail, the context is probably anchored to a bad path; use /clear and restart with a more precise first prompt.
Each prompt creates a checkpoint. Use /rewind to restore the conversation or file state produced by Claude's editing tools. Changes made by Bash commands and external processes are not covered by file checkpoints, so Git remains the final safety net.
/rewind
/clearOfficial sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology