Getting Started Practice: Take a Real Requirement from Kickoff to Delivery

📚 Series Navigation: The previous article 38 Plugins Reference taught you how to package your configuration into a distributable package. This article completely shifts gears—while the first 38 articles focused on "breaking down features one by one", this article connects them into a complete practice path for the first time: taking a real small requirement and walking through it in one go, from opening the project, writing CLAUDE.md, asking questions, reviewing changes, to verification and delivery. We will tie all the learned skills together.

To be honest, most people think writing code with AI is just "one prompt and wait for results"—you state your requirements, Claude runs it, and you take it. This path sounds smooth, but once you run into a pitfall, you know where it breaks:

The direction went off track, three extra files were accidentally modified, and the promised bug fix still crashed... In the end, the time spent cleaning up was more than doing it by hand.

It is not that the tool is not smart enough; it's just that a few key batons were dropped in the process.

To put it simply, this is the gap between "having learned each action" and "being able to connect the actions into a journey." You have practiced steering, checking mirrors, and tapping the brakes, but the first time you hit the road alone, you have to connect these actions in the correct order to be considered a driver. This article does not teach any new features, but does just one thing—leads you to connect the parts you already know into a runnable practice path for the first time.

The task we chose is as small as it gets, but it has everything: adding a feature to a small word-frequency counting script, and fixing a bug along the way. The sparrow may be small, but it has all its vital organs—no step is missing from the kickoff to delivery.

After reading this article, you will get:

• A standard practice path of "Kickoff → Explore → Plan → Action → Verify → Deliver", showing what to type and look for in each step
• A real small task you can copy (adding --top N to the wordcount script and fixing the empty parameter crash), with full commands + expected output
• Why the golden rule of "letting it explore first, then let it take action" is the muscle memory that beginners need to develop most
• How to use plan mode (detailed in Chapter 20) to make it propose a plan before writing code, and how to review the diff it provides
• A comparison chart of "How pros do it vs. How beginners do it", highlighting the most common sequencing pitfalls

---

01 See the Big Picture First: A Real-World Practice in Six Steps

Before taking action, go through the whole journey in your mind. For any real task from receipt to delivery, regardless of size, the backbone consists of these six steps:

Analogy: Passing the baton in a relay race. These six steps are like six runners passing a baton: Explore hands over "what I understand" to Plan, Plan hands over "how I intend to change it" to Action, and Action hands over "what was changed" to Verify. If any baton is dropped, the entire process has to be reworked—90% of beginner failures happen because a handoff was skipped, most typically "letting it take action directly without exploring," running before grabbing the baton.

These six steps are not made up; they are the practical sequence pieced together from the official quickstart and common workflows documentation. The official quote captures it perfectly:

Let Claude understand your code before making changes.

These six steps can be compressed, but not skipped. Experienced users might combine "Explore + Plan" into a single command, or link "Verify + Deliver" into one action, making it look like three steps—but every step is still there, just at a faster pace. What beginners do wrong is not "walking too slowly," but directly deleting the middle four steps, leaving only "stating requirements → getting results", which is like throwing the baton directly from the first runner to the finish line with no one in between. The rest of this article is to guide you to walk through these six steps step-by-step on a real task, handing off the baton personally every time. I will mark "what we learned in previous chapters" at the beginning of each step so you can connect the parts as you go.

💡 Summary in one sentence: The backbone of a real-world practice is always the six steps "Kickoff → Explore → Plan → Action → Verify → Deliver", where the baton must be passed properly at every step just like in a relay race; the most common baton beginners drop is "letting it take action directly without exploring."

---

02 Preparation: Create a Sandbox Project

To let you follow along exactly, we won't touch any real big projects, but instead spend two minutes building a minimal sandbox. It contains only a Python script and a text file, with no third-party library dependencies, requiring only python3 to run (pre-installed on Mac / Linux; just install Python on Windows).

Step 1: Create a directory, enter it, and put two files

Execute in the terminal (this step is purely manual preparation, before starting Claude Code):

mkdir wordcount-demo && cd wordcount-demo

Create a new wordcount.py with the following content (this is the legacy code we want to modify, intentionally written a bit roughly):

import sys
from collections import Counter

def count_words(path):
    with open(path) as f:
        text = f.read()
    words = text.lower().split()
    return Counter(words)

def main():
    path = sys.argv[1]
    counts = count_words(path)
    for word, n in counts.items():
        print(f"{word}: {n}")

if __name__ == "__main__":
    main()

Then create a sample.txt as test data:

the quick brown fox the lazy dog the fox

Step 2: Run it manually to confirm it works

python3 wordcount.py sample.txt

Expected output (the order might be slightly different, but the numbers will be the same):

the: 3
quick: 1
brown: 1
fox: 2
lazy: 1
dog: 1

Seeing these counts means the script works normally, and the sandbox is set up. This script has two problems, which will serve as our tasks:

• Missing feature: I only want to see the "top N most frequent words", but currently it prints everything.
• Hidden bug: Try running python3 wordcount.py without a filename; it will throw an IndexError crash in your face, instead of properly reminding you that "a file path needs to be provided".

Step 3: Put it under git (this step is crucial, don't skip it)

git init && git add . && git commit -m "init: 一个简陋的数词脚本"

Expected: A commit confirmation line similar to 2 files changed appears at the end (wordcount.py and sample.txt recorded). Seeing it means you already have a clean "starting point", and no matter what Claude changes the code to, you can return here with a single command.

Why should you always git commit before starting? Because it is your strongest safety net. Chapter 37 explained that checkpoints can rewind Claude's edits, but checkpoints and git are two different systems, handling different parts (discussed specifically in Chapter 37). A clean git commit before kickoff is your foundation for "returning to the starting point no matter how things get messed up later"—making major changes without committing first, then wishing to regret it but having no clean baseline to compare, is a very common lesson to learn the hard way. So, commit first without exception.

💡 Summary in one sentence: The sandbox has just one rough script + one text file, requiring only python3 to run; it intentionally leaves two tasks: "missing feature" and "hidden bug"; always git commit before starting to leave yourself the strongest safety net.

---

03 Kickoff: Start in the Project Directory and Write a Minimal CLAUDE.md

With the environment ready, let's start the first baton—Kickoff. This step corresponds to Chapter 02 (Starting), Chapter 07 (First Run), and Chapters 12 / 18 (CLAUDE.md).

Step 1: Start Claude Code in the project root directory

You must run claude inside the wordcount-demo directory, not elsewhere. Claude Code defaults to using "the directory where you started it" as the workspace—if you stand in the wrong place, it will read files from other projects.

claude

Expected: You see the Claude Code welcome screen, showing that the current directory is wordcount-demo at the bottom. This is the starting point that Chapter 07 guided you to run successfully.

Step 2: Give it a "minimal viable" CLAUDE.md first

Chapter 18 repeatedly emphasized: The most useless CLAUDE.md is one that spans 300 lines with Claude not following a single rule. So for sandbox projects, don't overdo it—3 to 5 lines explaining the most critical rules is enough. For our small script, there are really only two rules: how to run it, and how to verify it after modification. Have it generate it directly in the session (you can also write it manually, but letting it write is easier):

Help me create a CLAUDE.md in the project root directory with two rules:
1. This is a pure standard library Python command-line utility, do not introduce any third-party dependencies.
2. Every time the code is changed, run python3 wordcount.py sample.txt to verify no errors occur.

Expected: Claude will first show you what it plans to write, then request approval to write the file (the permissions mechanism explained in Chapter 20—it always asks before touching files). After approval, a CLAUDE.md will appear in the project root, with content looking roughly like this:

# wordcount-demo

A command-line utility to count word frequency in text.

## Technical Constraints
- Pure Python standard library, **do not introduce any third-party dependencies**.

## Verification
- Every time the code is changed, run to confirm no errors: `python3 wordcount.py sample.txt`

Short, but the two most critical rules are locked down. Don't think it's too simple—if 3 to 5 lines can govern the rules, there's no need to write 30.

Here you might think of /init from Chapter 12. The difference is: /init lets Claude scan the codebase itself and automatically generate a fairly complete manual, which fits real projects with some scale; our script has only two files, so manually specifying those two core rules is more accurate and shorter. Both ways are fine, choose based on project size.

Why spend this step writing CLAUDE.md at kickoff? Because it defines the "general rules" for all subsequent batons. Later, when you ask it to add features, it will automatically remember "no third-party dependencies"; after modifications, it will automatically remember "run the verification"—you only say it once, and it remains effective throughout, saving you from repeating it in every instruction. This is the most practical value of CLAUDE.md: fixing "things you need to say every time" as a background loaded automatically in every session.

💡 Summary in one sentence: Kickoff = run claude in the correct directory + write a minimal 3-5 line CLAUDE.md to lock down the core rules; manually specifying two rules for sandbox projects is more accurate and shorter than scanning the whole repo via /init.

---

04 Explore: Let It "Understand" First, Don't Rush to "Action"

This is the baton in the journey that should become muscle memory, yet is most easily skipped by beginners—Explore. This corresponds to the first category in Chapter 16, "Four Most Common Tasks."

Conclusion first: The first sentence you say upon receiving a task is not "change it for me," but "understand it first."

The frozen scenario at the beginning made exactly this mistake—trying to type "add a --top parameter to the script" right off the bat. What's bad about it? Claude knows nothing about your code; it will guess as it edits, and if it guesses wrong, it will end up with a mess. The correct way is to first send it to explore the current state:

Don't modify any code yet. Tell me how @wordcount.py works now,
where the entry point is, and whether there are any obvious issues or places prone to crashing?

Note two details:

• The starting phrase "Don't modify any code yet" draws a line for it—in this step, it is only allowed to look, not touch. As explained in Chapter 15, clarifying the boundaries prevents it from crossing them.
• The @wordcount.py uses @ to feed the file content directly into the conversation (the @ reference mentioned in Chapters 16 and 17), saving it from looking around.

Expected: Claude will read the file and explain it—roughly saying: this is a script that counts word frequency using Counter, the entry point is main(), it retrieves the file path from sys.argv[1], and then it will likely point out the potential issue: if no filename is passed, sys.argv[1] will go out of bounds and crash.

See that? Before you even mentioned the bug, it discovered it on its own during exploration. This is the bonus of "exploring first": it not only understands the current state but also helps you spot the problem. Handoff this baton well, and the next baton (Plan) will be on track.

Since this script has only a dozen lines, one exploration query is enough; but in real projects, exploration often needs to go "from broad to narrow" in multiple levels. The exploration routine in the official common workflows follows this rhythm: ask about the global state first, then drill down to details—

First give me the overall structure of this repository and what it does (don't change any code yet)

In which files is the user login logic located? How do they work together?

The first query gets a "global map," and the second follows the map to drill down into the specific area to modify. Why not ask about details right off the bat? Because the less concept it has about the project, the more likely it is to mistake "seemingly related" files for "truly related" ones—providing a global map first makes its subsequent positioning accurate. When entering an unfamiliar medium-sized project, always start with these two or three queries. It is better to spend an extra two minutes exploring than to let it make modifications based on an incorrect global impression.

Analogy: Walking around the car once before hitting the road for the first time. An experienced driver takes a quick glance before getting in—checking if tires are flat, if there are obstacles behind, or if mirror angles are correct. This walk takes less than ten seconds, but it avoids "shifting into gear and hitting an unseen pillar." Letting Claude explore first is like this walk—a ten-second "glance" saves you half an hour of "fixing mistakes and starting over" later.

Reading files during the exploration phase consumes context (as discussed in Chapter 19, a cluttered workspace makes it slow down). For large tasks requiring browsing many files, you can spawn a subagent to explore (Chapter 23)—the subagent browses in its own window and returns only the conclusions, keeping your main conversation from being filled with file contents. This is not needed for small tasks, but it is good to know.

💡 Summary in one sentence: The first sentence upon receiving a task should always be "don't change anything yet, understand it first"; letting it explore not only avoids guessing and messy changes, but also often yields a bonus "problem it spots on its own"—this baton is the one beginners must train into an instinct.

---

05 Plan: Let It Propose a Plan First, You Approve Before Writing Code

After exploring, it understands the current state and knows what you want. But there is one step left—letting it lay out "how it plans to make the changes" for your review, and only taking action once you approve. This baton corresponds to the plan mode in Chapter 20.

Why not just let it edit directly? Because "the solution it understands" might not be "the solution you want". Letting it explain the plan first is the cheapest insurance to prevent it from going completely off track and changing everything.

Method 1: Ask it to state the plan first without taking action

The simplest way is to constrain it with one sentence:

I want to add a --top N parameter to this script, only showing the top N most frequent words;
fix the crash when no filename is passed along the way.
First tell me how you plan to change it and which parts will be modified, and wait until I say "start" to take action.

Expected: It will return a plan, such as—replacing the manual sys.argv with argparse, adding a --top option, using Counter.most_common(N) to retrieve the top N items, and having argparse automatically report a user-friendly tip instead of crashing when no filename is provided. It will pause here waiting for your decision, without modifying files on its own.

Method 2: Formally use plan mode

For larger tasks, it is safer to switch to the official plan mode—it will force Claude not to edit source code and only produce plans, not changing a single line without approval (though it can still run shell commands to explore). There are two ways to enter this mode (discussed in Chapter 20):

claude --permission-mode plan

Or press Shift+Tab in the session to cycle to plan mode. The official positioning is very clear:

Claude reads files and proposes a plan, but does not make edits until you approve.

The difference between these two approaches is summarized in the table below:

Approach	How to constrain it	Level of enforcement	Suitable for
Ask it to state the plan first via a prompt	Rely on writing "don't take action yet" in your prompt	Soft constraint (it usually listens, but is not physically blocked)	Small changes, when you are actively supervising
plan mode	At the mode level, source code edits are banned (shell commands can still run)	Hard constraint (not a single line of source code can be modified before approval)	Large changes, when you feel uncertain and want to review plans carefully

A useful habit: For small changes like this --top parameter, Method 1's single sentence is enough; but for any changes involving multiple files or when you feel uncertain, switch to plan mode using Shift+Tab without exception—letting the mode guard the gate of "no modifications without approval" is much easier than hovering over it. If you make a large change in an unfamiliar project and skip switching to plan mode out of a desire for speed, it might modify four files in one go in a direction completely different from what you wanted. The time spent rolling back would be enough to review the plan three times. So, when in doubt, use plan.

💡 Summary in one sentence: Before writing code, let it propose a plan first and only edit after you approve; a single sentence "don't edit yet" suffices for small changes, while large or uncertain changes should use Shift+Tab to switch to plan mode to hard-lock code edits prior to approval.

---

06 Action + Review: Let It Make Changes, but Look Over Every Diff

With the plan approved, here comes the sixth baton (actually a combined action and review baton)—let it change, while you keep an eye on every single edit. This corresponds to the permission confirmation in Chapter 20.

Step 1: Give it the green light

The plan looks good. Go ahead and start making the changes.

Expected: Claude starts editing wordcount.py. Here is the key part—with each edit, it presents the diff (showing deleted lines and added lines) before you, requesting approval (unless you enabled the "accept all" mode, which beginners are strongly advised not to do). This is where the permission mechanism explained in Chapter 20 actually takes effect.

Step 2: Review the diff carefully, don't blindly hit Enter

This is the easiest place for beginners to get sloppy—blindly hitting y without looking at the diff as it scrolls by. My golden rule is: take at least a quick glance at every edit to confirm "is it modifying the place I asked it to?" The changes you should see in this task look roughly like this:

- import sys
+ import argparse

- def main():
-     path = sys.argv[1]
-     counts = count_words(path)
-     for word, n in counts.items():
+ def main():
+     parser = argparse.ArgumentParser(...)
+     parser.add_argument("path", ...)
+     parser.add_argument("--top", type=int, default=None, ...)
+     args = parser.parse_args()
+     counts = count_words(args.path)
+     items = counts.most_common(args.top) if args.top else counts.most_common()
+     for word, n in items:

Glance over it to confirm three things: ① It is indeed adding --top and modifying the input arguments (matching the plan); ② It didn't accidentally touch the count_words function, which was already fine; ③ It didn't sneak in any third-party libraries (complying with CLAUDE.md). If they match, approve it.

How to quickly scan a diff? You don't need to read it word by word; just spot three signals: make sure red lines (-, deletions) don't contain things you want to keep; make sure green lines (+, additions) don't include dependencies or features you didn't ask for; and check that the scope of changes doesn't exceed the areas you discussed. In this task, the red lines remove the manual sys.argv, green lines add argparse and --top, and the scope is strictly within main()—everything is within expectations, so approve with confidence.

A piece of advice for beginners regarding the "accept all" mode: don't enable it during the practice phase. The quickstart mentioned you can "enable auto-accept mode for the session" (which is acceptEdits discussed in Chapter 20). If enabled, it won't ask you for each edit and will just modify files all the way. It saves effort, but at the cost of completely giving up the "in-flight intercept" window. The safer approach is to only enable it in two cases: first, when the changes have already been reviewed line-by-line in plan mode and you feel confident; second, during highly repetitive mechanical changes (such as bulk-renaming a variable). For the first month or two, read each edit one by one, and train your eye for diffs before letting it run on autopilot.

Why is the review step indispensable? Because AI coding is not a binary right-or-wrong system; it is often "mostly correct but slightly off in the details"—it might modify extra places you didn't ask for, or use code styles you don't want. The quote from Chapter 20 is worth pasting again:

Claude Code always requests permission before modifying files.

This permission is not a formality; it is your only window for "in-flight interception"—once approved and written, you must rely on checkpoints from Chapter 37 or git to "roll back after the fact," which costs significantly more. Glancing at a diff during the change is always more cost-effective than rolling back afterwards.

💡 Summary in one sentence: During the action phase, let it make changes, but look over every diff—confirming that "it's modifying what should be modified, not messing with good code, and not violating CLAUDE.md"; this approval is your only window for in-flight interception, and blindly hitting Enter means leaving the safety net for after-the-fact cleanups.

---

07 Verify: Run It to Show You, Don't Believe "I Fixed It"

Once the code is modified, it will likely say something like "I've modified it, added the --top parameter, and fixed the crash issue." Do not believe a single word of this until you see it run successfully with your own eyes. This is the second-to-last baton of the journey, and the one beginners love to skip the most.

Conclusion first: "It says it's fixed" doesn't count; "running it and getting it right" does. This is exactly the strict requirement in the project guidelines—"actively verify after modification, do not just change without verifying." In practice, this means—running the acceptance criteria yourself.

Step 1: Verify the new feature (--top)

python3 wordcount.py sample.txt --top 3

Expected output (sorted by word frequency from highest to lowest, showing only the top 3):

the: 3
fox: 2
quick: 1

Seeing only the top three and sorted by frequency means the new feature works. (the appears 3 times, fox 2 times, and the third place is any of the words that appear once.)

Step 2: Verify old features aren't broken (regression)

After adding the new parameter, the old usage must not break—running without --top should still print everything just like before:

python3 wordcount.py sample.txt

Expected: Consistent with the original output in Section 02 (all six words are present). Consistency means no "fixing the new while breaking the old".

Step 3: Verify the bug is indeed fixed

This step is the most crucial—reproduce the original crash and check whether it shows a friendly reminder now instead of throwing a traceback:

python3 wordcount.py

Expected: No longer the IndexError crash, but a clean usage message, similar to:

usage: wordcount.py [-h] [--top TOP] path
wordcount.py: error: the following arguments are required: path

Shifting from "the program crashing and throwing a traceback in your face" to "explicitly telling you that path is missing"—this is the ironclad proof that the bug is fixed. Once all three steps pass, the task is truly complete.

Want to be even more secure? Let it write a test to lock down the verification. The three steps above were run manually, and once they passed, it was over; but the next time someone edits the code, the same bug might crash again. A more robust way is to let Claude write a small test, turning "friendly error when no filename is passed" into a repeatable gate. The official common workflows specifically mention "when fixing a bug, write a test that reproduces it first, then make the test pass" (the guideline "write a test reproducing the bug, then make it pass" is for this exact reason):

Write a test for "no crash when no filename is provided, but exit with non-zero code and print usage information", and confirm it passes.

Expected: Claude writes a short test (running the script via subprocess, asserting exit codes and output), and runs it to show you a green light. This step upgrades "I ran it successfully this time" to "it will be verified automatically every time in the future"—it is the icing on the cake for practice, but an absolute necessity for real projects. You can skip it if you feel it is too heavy for small tasks, but you must keep this concept in mind.

Why be so strict about "running it yourself"? Because more than a few people have been burned by "I've fixed it." You ask it to fix an edge case, it confidently claims it is fixed, commits it without running, and it turns out the edge case wasn't covered at all—it changed another place that just "looked related." So hold onto this truth: the "done" claimed by AI is a hypothesis; the "passed" run by you is the fact. This matches the rule in the project guidelines: "Whenever a verification is claimed, it must actually be run."

💡 Summary in one sentence: Verification = run it three times yourself—checking if the new feature works, if old features are intact, and if the bug is truly fixed; "it says it's fixed" is a hypothesis, while "you run it successfully" is the fact; this baton cannot be skipped.

---

08 Delivery: Let It Write the Commit Message and Save the Work to the Repo

With all three verification steps passed, the final baton is—Deliver, saving the results safely in git. This corresponds to the "conversational git" mentioned at the end of Chapter 07.

Step 1: Check what was actually changed

Which files did I change? Give me an overview of the changes.

Expected: Claude runs git status / git diff, telling you that only wordcount.py was modified this time, with the --top parameter added and input argument parsing replaced by argparse. Confirming once more before delivery that "the scope of changes aligns with expectations" serves as a final review.

Step 2: Have it generate a commit message and commit

Describe this change clearly in one sentence and commit it.

Expected: Claude will first show you the proposed commit message—such as "feat: add --top N parameter to wordcount and fix missing arg crash using argparse"—then request approval to run git commit. This is again the permission gate from Chapter 20: before modifying your git history, it still asks you first.

A quick note on an important boundary here: git commit will ask you to confirm the changes first; but git push (pushing to remote) is a different story. Before pushing work to remote repositories like GitHub, you must be fully aware and handle it yourself—this is discussed in detail in Chapter 43 "Git Workflows". For now, remember: you can let it handle local commits, but keep pushing to remote in your own hands.

Step 3: Confirm successful commit

Show my last commit.

Expected: It runs git log -1, displaying the commit message and changes. Seeing it means the task is officially delivered, achieving a full loop from kickoff to codebase entry.

Reaching this point, look back: from a crashing, incomplete rough script to a tool with --top parameter that reports friendly tips on missing arguments, you typed only six or seven natural language prompts in total—but each sentence fell right into its correct place in the six steps. This is what "connecting the parts into a journey" looks like.

💡 Summary in one sentence: Delivery = check change overview → let it draft commit message and run commit (it will ask for confirmation first) → run git log to verify entry; remember the boundary—local commits can be delegated, but keep pushing to remote in your own hands (saved for Chapter 43).

---

09 What if Things Go Wrong: Roll Back Cleanly, Don't Patch on Top of a Mess

The journey above went smoothly because we intentionally chose a small task. Real-world tasks are rarely this well-behaved—the verification step often fails (red light): features are not implemented correctly, or other parts are broken. At this moment, a beginner's instinct is often wrong: asking it to "fix it on top of" the code that has already been messed up.

Don't do that. Repeatedly patching on top of an already-deviated state makes it messier—it carries the wrong context from the previous attempt each time, making it easy to dig a deeper hole. The correct approach is: roll back cleanly to a known correct point first, then restart with how to state the requirement more clearly. This is exactly where the checkpoints from Chapter 37 and the pre-kickoff git commit from Section 02 come in handy.

There are two rollback levels, depending on how far you went:

Rollback Level	What to use	Roll back to	Suitable for
Light level: Undo the latest edits	Checkpoints from Chapter 37, /rewind	Before Claude edited this batch of files	Messing up one or two spots, noticed immediately and want to revert
Heavy level: Return to kickoff starting point	git, git restore . / git reset --hard	The clean commit before kickoff	The entire direction went off track, want to restart from scratch

The light level is most commonly used: type /rewind in the session, and it will rewind Claude's file edits for this round (Chapter 37 specifically discussed its boundaries—it can revert files and chat history, but don't treat it as git). The heavy level is the fallback: if things are altered beyond recognition and checkpoints cannot sort them out, return to the kickoff commit from Section 02—this is why we insisted on a git commit before starting. That clean commit is the origin you can always escape to.

Don't rush to say the same prompt again after rolling back. First think about why it went off track this time—90% of the time, exploration wasn't sufficient or instructions were too vague (the "speak clearly" rule in Chapter 15). One tip: if it deviates on the first attempt, 90% of the time, the instruction missed a key constraint, such as failing to specify "only modify this function, don't touch anything else." Rolling back to the origin and making the prompt more specific usually makes the second attempt successful. Rolling back is not a failure; it is loss control—it saves far more effort than patching on top of a mess.

💡 Summary in one sentence: When edits go off track, the first reaction should be "rolling back cleanly", not "patching on top of a mess"; use /rewind for a light rollback to undo edits, and git for a heavy rollback to the kickoff starting point (which is exactly what the pre-kickoff commit is for); refine your instructions after rolling back before trying again, instead of repeating the same prompt.

---

10 Comparison: How Pros Do It vs. How Beginners Do It

The same six steps yield vastly different results for pros and beginners—the difference lies entirely in those "skipped batons". I have listed the most common pitfalls side-by-side for you to self-check:

Phase	❌ Beginner Pitfalls	✅ Pro Workflows
Kickoff	Run claude in any random directory, no CLAUDE.md	Stand in the correct project directory, write a minimal 3-5 line CLAUDE.md to set rules first
Explore	Jump straight to "modify it for me," skipping understanding	First sentence is always "don't change anything yet, understand it first", letting it explore the current state
Plan	Let it edit directly, realizing the direction went off track only after the fact	Let it propose a plan first, approve before editing; switch to plan mode when uncertain
Action	Hit y all the way without even looking at the diffs	Glance at every diff: checking if modifications are correct and within bounds
Verify	Believe "I've fixed it" and wrap up	Run it three times yourself: verifying the new feature, old features, and the bug respectively
Deliver	Leave it there after editing, or commit directly without checking the scope	Check change overview first, let it draft commit message, run log to verify codebase entry

The essence of this table is simple: beginners compress six steps into two (stating requirements → getting results), while pros patiently walk through all six steps. When starting out, everyone loves shortcuts, but after getting burned by "deviating direction + committing without verifying" a few times, you gradually learn to run these six steps smoothly. The ones you should train into instincts first are the head and tail batons—"exploring first" at the start and "verifying yourself" at the end; if you hold down these two batons, the chance of a major crash decreases significantly.

Another common question is: "Isn't running through these six steps every time too tedious?" Not at all, because the smaller the task, the faster each step is—for our practice task here, running through all six steps takes less than ten minutes. Furthermore, once you get used to it, Explore and Plan can often be combined into a single sentence ("understand @file first and tell me how you plan to modify X, don't make changes yet"). The workflow is a backbone, not shackles; once the backbone is memorized, how you play the rhythm is up to you.

💡 Summary in one sentence: The gap between pros and beginners lies entirely in "whether a baton was skipped"; the ones that must become instincts are the head and tail batons—"explore first" at the start and "verify yourself" at the end; the smaller the task, the faster each step runs—six steps are a backbone, not shackles.

---

Summary

This article did not teach any new features, but did just one thing—guided you to connect the parts learned in the first 38 chapters into a complete practice path on a real small task for the first time.

Let's replay the prompts you typed throughout the process in sequence, and you will notice it takes just six or seven sentences, with each sentence corresponding to a baton handoff:

# After Kickoff (Set rules first)
Help me create a CLAUDE.md: pure standard library with no third-party dependencies; run python3 wordcount.py sample.txt to verify after editing

# Explore (Understand first, don't edit)
Don't modify any code yet. Tell me how @wordcount.py works and if there are any places prone to crashing?

# Plan (Propose plan, wait for approval)
I want to add --top N to show only the top N words, and fix the crash when no filename is passed along the way. Propose a plan first, and wait until I say start to take action.

# Action (Approve and proceed, then review diffs one by one)
The plan is good, go ahead and start modifying.

# Verify (Run it yourself, don't just take its word)
(Back to terminal: run with --top 3 / without top / without filename, verifying all three cases)

# Deliver (Check scope → commit → confirm)
Which files did I modify? → Describe this change in one sentence and commit it. → Show my last commit.

Do you see it clearly now—real "practice" is just these few natural language sentences. The difficult part is never the wording, but placing each sentence in the right position. Let's review the six steps connected together:

Step	What to do	Relevant Chapters	Key point in one sentence
Kickoff	Start in correct directory + write minimal CLAUDE.md	02 / 07 / 12 / 18	Rules stated once, effective throughout
Explore	Let it understand code first, don't take action	16	First sentence is always "don't change anything yet, understand it first"
Plan	Let it propose plan, you approve	20 (plan mode)	Switch to plan mode using Shift+Tab when uncertain to hard-lock edits
Action	Let it edit, glance over every diff	20 (permission confirmation)	In-flight interception is more cost-effective than rollback after the fact
Verify	Run it yourself, don't believe "I've fixed it"	16 / 37	The "passed" run is the fact
Deliver	Check scope → draft commit message → enter codebase	07	Local commits can be delegated, but keep pushing in your own hands

You should now be able to: receive any real small requirement like "help me add a feature / fix a bug for something" and no longer freeze in front of the terminal not knowing which command to type first. Just keep the six steps (Kickoff, Explore, Plan, Action, Verify, Deliver) in mind and pass the baton properly step by step. In particular, hold down the head and tail batons "explore first, verify after", so that Claude neither guesses wildly nor fails to run successfully. Once this workflow runs smoothly, all the components learned in the previous chapters will truly come alive, working together as one to get things done.

This chapter is a watershed—from here on out, we assume you "know how to connect the parts into a journey", and the next few chapters will continue to add new skills to this practice path.

---

The next chapter 40 "Chrome: Letting It Operate the Browser"—in this practice run, Claude worked entirely with "local files + command-line". In real work, however, how many tasks must be completed in the browser: filling out forms, clicking around pages, scraping web data, or styling based on actual rendering. The next chapter connects it with the browser as a "hand," moving it from "only editing code" to "clicking the mouse for you." Think about it—when Claude can not only change your code but also open the browser to operate it, the work it can help you with will expand significantly.

---

Recommended Reading

• JetBrains Integration
• Output Styles: Change the Show, Not the Host
• Four Most Common Tasks: Exploring Codebases, Fixing Bugs, Refactoring, Writing Tests