Claude Code: Advanced Usage Experience Sharing

Many people find Claude Code extremely powerful when they first start using it.
But as you go further, what really sets people apart is not "knowing what it can do," but "whether you have a stable workflow."

The most common state for beginners is:

• Asking whatever comes to mind
• Asking Claude to make direct changes right off the bat
• Not verifying after changes are made
• Treating every round like starting from scratch

Advanced users, on the other hand, are more like "leading Claude through a structured process to push tasks forward."

The role Claude Code is best suited for is not "writing everything for you all at once," but rather:

• Helping you quickly understand the project
• Helping you break down implementation plans
• Helping you execute repetitive or high-density work
• Helping you verify and review

In other words, the smoothest way to use it is usually not:

Throwing a massive goal directly at Claude and waiting for a miracle to happen

But rather:

Letting Claude understand first, then plan, then execute, and then verify

Because it simultaneously solves several common problems:

• Making messy, impulsive changes right from the start
• Making changes but not verifying them
• Changes being too scattered to clearly explain even to yourself
• Lacking a code review perspective after completing the work
• Mixing analysis, implementation, review, and commit in a single session, making it impossible to tell them apart in the end

In other words, this isn't "more troublesome"—it's "more stable."

You can directly assign tasks to Claude Code like this:

First analyze which files this requirement will involve, provide an implementation plan and risk points, and do not modify the code yet.

Start making modifications after confirmation. Once modified, run the build and related tests.

Finally, check for potential issues from a code review perspective.

The benefit of this kind of prompt is that it breaks the task down into:

• Understanding
• Planning
• Execution
• Verification
• Review

This is much stronger than "help me build this feature."

This is the most common and highly recommended workflow for long-term use.

• Adding new pages
• Adding an API endpoint
• Adding new capabilities to existing modules
• Needing to modify multiple files, but with relatively clear boundaries

1. Have Claude understand the relevant modules first
2. Output the implementation plan and the files involved
3. Start modifying code after confirmation
4. Run builds and tests
5. Perform a review
6. View diff and commit

• /plan
• /diff
• /review
• /commit

First take a look at which files this feature will affect, and provide a minimal implementation plan. Do not modify the code yet.

Start modifying after I confirm. Once modified, run the build and related tests, and finally do a review.

When fixing bugs, many people tend to let Claude start modifying things right away.
But a more reliable way is actually to "locate first, then fix, then reproduce and verify."

• Page errors
• API anomalies/errors
• State confusion/mismatches
• Flaky/occasional bugs in a specific scenario

1. Have Claude restate the problem and the troubleshooting direction first
2. Search the relevant call chain and error locations
3. Provide a root cause hypothesis
4. Explain the fix first, then touch the code
5. Verify in a way that closest mimics the real issue

Do not modify the code yet. First help me locate which layers this bug might be in.

List the most likely root causes, relevant files, and fix ideas. Modify only after confirmation.

After modifying, please try your best to reproduce and verify if the issue is truly resolved.

Because bug fixing dreads two things above all:

• Fixing the wrong place
• Not verifying the actual problem after the fix

These types of tasks are the easiest to spiral out of control, because the goals are often not as concrete as "building a feature."

• Files too large and needing split
• Too much duplicated logic
• Messy naming and structure
• Unclear boundaries between components, services, and utility functions

1. Have Claude evaluate the current structural issues first
2. Clarify "which specific type of refactoring to do this time"
3. List the splitting plan first
4. Modify in batches; do not refactor the entire system in one go
5. Verify each batch

First evaluate the most major structural issues in this module, and give me only the 2 to 3 most worthwhile refactoring points.

Do only the minimal round this time, and do not incidentally modify too much unrelated content.

After modifying, explain what specific responsibilities were split, and run verification.

Be sure to limit the scope.
Otherwise, Claude can easily "incidentally optimize" a massive pile of extra changes.

This scenario is particularly suitable for Claude Code, as it is highly skilled at helping you build a cognitive map first.

• Taking over a repository for the first time
• Needing to temporarily fix something in someone else's project
• You are unfamiliar with an old company project
• Wanting to quickly find out where a certain feature is implemented

1. Have Claude build a project map first
2. Then lock onto the directories and files most relevant to the current goal
3. Then proceed to planning and modification

Help me quickly understand this project first:

1. What is the tech stack?
2. What are the main directories responsible for?
3. Which files is this requirement most likely to involve?

Do not modify the code yet.

Have Claude write a CLAUDE.md file for you while it's at it.
This way, when you come back a second time, the project won't feel so unfamiliar.

Particularly suitable for the following scenarios:

• Changes span across multiple modules
• Involves database, permissions, and API interactions
• You haven't fully figured out the concrete implementation yourself
• You want Claude to provide a complete step-by-step plan first
• You are worried it will directly modify the code without fully thinking it through

If you already feel in your mind that "this task is a bit big," then /plan first.
The biggest value of Plan Mode is not being more formal, but helping you turn "ideas" into "execution steps."

/plan

Suitable for kicking off large tasks.

/diff

Suitable for:

• Seeing what Claude actually modified
• Avoiding relying solely on its verbal summary

/review

Suitable for:

• Looking over bugs, risks, and missing tests one more time before committing

/context
/compact

Suitable for:

• The conversation is already very long
• You feel Claude is starting to "forget things"
• Wanting to continue the current task but not wanting to start a completely new session

/diff
/review
/commit

This is basically a complete wrap-up pipeline.

Don't let Claude rush in and start modifying directly.

Once modified, always have it run build, test, or key commands.

Document long-term constraints here instead of dictating them verbally every time.

For example, explicitly say:

• Don't refactor yet
• Only fix this bug
• Do not incidentally modify unrelated files
• Provide a minimal implementation first

Don't just look at Claude's summary; check the actual changes.

Resolving one clear goal per round is much more stable than finishing the entire requirement in one breath.

Symptoms:

• Claude starts giving irrelevant answers
• Forgetting previously confirmed constraints
• Modifications become increasingly drift/unfocused

Solution:

• Use /context to check usage
• Use /compact
• Start a new session when necessary and re-establish goals

Symptoms:

• You originally wanted to discuss plans first
• Claude starts modifying right away

Solution:

Explicitly write:

Do not modify the code yet, only analyze and provide a plan.

Symptoms:

• Claude claims "already completed"
• But actually skipped running key verifications

Solution:

Be specific about verification actions:

• Run npm run build
• Run related tests
• Launch the local page to verify
• Provide failure outputs

Claude can help you push tasks forward, but whether to ultimately commit, go live, or accept a plan is still up to you.
The point of an advanced workflow is not "completely letting go," but "letting Claude help you form a reliable closed loop faster."

If you don't want to memorize too much, sticking to this one set is enough:

If you follow this rhythm every time, the stability of Claude Code will improve significantly.

The core of an advanced workflow is not being more complex, but more rhythmic:

• Understand first
• Then plan
• Then execute
• Then verify
• Finally, review and commit

Once you build this habit, the value of Claude Code will be much higher than "asking whatever comes to mind."
It will transform from "a very powerful AI tool" into "an engineering partner truly integrated into your development process."