How to Run Projects with Claude Code (Claude CLI)

To turn Claude Code (Claude CLI) into a driving force for your projects rather than just a "handy autocomplete tool," you need a deliberately designed workflow that cycles through planning, implementation and verification. In this article, we distill a reproducible approach from official documentation and our research into practitioners' blogs.

This article is our summary, written in our own words, of official documentation and technical blogs published in English, with the key points organized for readers. The source for each technique is listed in the "References" section at the end of the article. For details, be sure to consult the original articles.

The Basic Flow: Explore -> Plan -> Code -> Commit

The core approach recommended by Anthropic is a four-phase loop of "explore -> plan -> implement -> commit" (Reference 1).

1. Explore: In plan mode, read the relevant files and understand them without making changes.
2. Plan: Have Claude draft a detailed implementation plan, which a human reviews and edits.
3. Code: Leave plan mode, implement the plan as written, and verify the result.
4. Commit: Commit the changes and open a pull request.

At the same time, the docs note that you can "skip the plan for a change you can describe in a single sentence," so the key is to match the weight of the plan to the complexity of the task. You can toggle plan mode with Shift+Tab, or specify it at launch with claude --permission-mode plan (Reference 2).

Keep the Plan as a Deliverable (a Document)

Many practitioners do not leave the plan in an ephemeral chat; they save it as a file. Harper Reed uses a powerful reasoning model to generate spec.md (the specification) and prompt_plan.md (the steps), then works through the tasks while tracking the completion status of each. He says "the robots love TDD. They really do," and prevents scope drift by creating the tests and mocks before the implementation (Reference 3).

Les Orchard likewise has the AI generate a plan.md from a short spec.md, describing it as "iterate on the plan: edit it, have the AI critique it, answer its questions, and repeat." Once the plan is solid, he starts implementation in a fresh session armed only with the plan and the existing code, avoiding context bloat (Reference 4).

Make CLAUDE.md the Project's Memory

Concentrate your project-specific rules in CLAUDE.md. The common advice is to "keep it short, period." Several sources suggest around 60 lines as a guideline and warn that a bloated file "causes the actual instructions to be ignored."

• Generate a starting point with /init, commit it to git, and grow it as a team.
• Apply the test to each line: "Would Claude make a mistake if I deleted this? If not, cut it."
• Reference details via links or @path imports rather than cramming them into the body (progressive disclosure).
• Run a self-improvement loop where, every time you fix a bug, you "add a one-line rule so the same thing does not happen again."

Close the Verification Loop (Often TDD)

The most universal technique is to give Claude a pass/fail check it can run on its own. TDD in particular (write the test first, confirm it fails, commit, and implement until it goes green) is repeatedly recommended as an "external oracle that does not go off the rails even as a session grows long." It is also important to demand evidence—asking "show me the test output" rather than accepting "it works" (References 5 and 6).

Parallelization and Checkpoints

As things scale up, run multiple tasks in parallel using isolated sessions with git worktree (claude --worktree feature-auth). Headless mode claude -p is useful for CI and bulk transformations across many files. That said, practitioners agree that "the degree of parallelism is decided by your own review capacity, not the tool's limit (two or three is a good rule of thumb)" (References 2 and 6).

In addition, the recommended practice is to use small, frequent commits as "save points," rolling back if something goes wrong (Reference 4). For steps where you want formatting and tests to run reliably, ensure them with a deterministically firing Hook (such as PostToolUse) rather than an advisory CLAUDE.md (Reference 6).