How to Use Claude Code: Tips, Tricks, and Workflows for Solo Builders

Most people use Claude Code like a fancy autocomplete. They type a prompt, get code back, copy it into their file, and repeat. That is leaving ninety percent of the tool unused.

Claude Code is a terminal-native agent. It reads your entire codebase, runs shell commands, edits files, executes tests, and iterates. If you are using it like a chat box, you are not using it.

This is for people already building with AI who want better results from Claude Code. Not how to install it. How to get it to do real work.

Start Every Session With a CLAUDE.md

Claude Code reads a CLAUDE.md file at the root of your project every time it starts. This is the single highest-leverage thing you can configure.

What belongs in CLAUDE.md:

• Project description: what this is, what stack it uses, what problem it solves
• Architecture overview: how the folders are structured, where things live
• Commands: how to run tests, build the project, start the dev server
• Coding standards: naming conventions, comment style, things to avoid
• Context about anything unusual: legacy decisions, workarounds, known debt

A minimal example:

# Project: Billing API

## Stack
Node.js, Express, PostgreSQL, Redis. TypeScript throughout.

## Commands
- `npm test` — runs Jest test suite
- `npm run build` — TypeScript compile
- `npm run dev` — starts local server on port 3000

## Architecture
- `src/routes/` — Express route handlers
- `src/services/` — business logic layer
- `src/db/` — database queries (never write raw SQL outside here)
- `src/middleware/` — shared middleware

## Standards
- No `any` in TypeScript. Use proper types or `unknown`.
- All database calls go through the service layer, never direct from routes.
- Every new route needs a test in `tests/routes/`.

This is not a README. It is a context file for your agent. Write it like you are briefing someone who has never seen the project but is about to make changes to it.

Without CLAUDE.md, Claude Code will figure things out by reading your files. With it, it starts fast and makes fewer wrong assumptions.

Give Tasks, Not Questions

The biggest mindset shift: Claude Code is not a consultant. It is a contractor. It executes.

Weak prompt (asking):

"What would be the best way to add rate limiting to my API?"

Strong prompt (tasking):

"Add rate limiting to all routes in src/routes/. Use Redis (already configured in src/db/redis.ts). Apply token bucket algorithm, 100 requests per IP per minute. Log blocked requests. Add tests."

The weak prompt gets you an essay about rate limiting options. The strong prompt gets you working code.

The formula: tell it what to build, where to build it, what constraints apply, and what done looks like.

Use the Slash Command System

Claude Code has a built-in slash command system. These are not shortcuts — they are programmable behaviors you define once and invoke by name.

The commands you will use most:

/compact — Summarizes the current session context to free up token budget. Use this when you are deep in a long session and responses start getting slower or less accurate. It compresses what happened without losing the thread.

/clear — Resets the context entirely. Use when switching to a completely unrelated task in the same project. Starting fresh is better than carrying irrelevant context.

/review — Reviews recent changes and flags issues before you commit. Good habit before every git commit in an active Claude Code session.

/help — Lists available commands. Run this when you first set up a new project.

You can also create custom slash commands as project-level skills. These live in .claude/skills/ and run as agents within your project context. A custom skill you define once (/deploy, /test-suite, /release-notes) can be invoked any time in any session.

The slash command system is what separates occasional Claude Code users from people who have automated their entire development workflow.

Set Up Your Permissions Model

Claude Code asks for permission before taking actions. By default, it asks before running bash commands, editing files, and calling external services.

You can configure which actions auto-approve and which require confirmation in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Edit(src/**)",
      "Write(src/**)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push)"
    ]
  }
}

The practical principle: auto-approve everything that is read-only or reversible. Require confirmation for anything that touches external systems, deletes data, or is hard to undo.

For most solo builders, the right configuration is:

• Auto-approve: run tests, read files, edit files within src/, write new files within src/, run build commands
• Always confirm: git push, database migrations, API calls to production, any rm commands

Getting permissions right eliminates the interruption loop. Claude Code stops asking about safe things and keeps asking about risky things.

Checkpoint Patterns for Long Tasks

Claude Code can run for dozens of tool calls on a complex task. Long sessions drift. Context gets stale. The agent makes assumptions that made sense thirty steps ago but do not make sense now.

Two patterns that prevent this:

The Milestone Check

For tasks that span more than four or five files, add explicit checkpoints to your prompt:

"First, read the current auth middleware and summarize what it does. Stop and confirm before making any changes. Then add the session token validation. Stop and confirm before running tests. Then run the test suite and show me results before committing anything."

Breaking the task into confirmed stages prevents the agent from building on a wrong assumption for twenty steps before you notice.

The Todo List Pattern

For complex multi-part tasks, ask Claude Code to write its own todo list before starting:

"Before making any changes, write a markdown todo list of every file you expect to modify and every step you will take. Show me the list. Then I will confirm and you can proceed."

This does two things. It forces the agent to plan before acting. And it gives you a shared mental model of what the task looks like, so you can catch scope creep before it happens.

For very long tasks, you can also save the todo list to a file (TASK.md) and have Claude Code update it as it completes each step. This creates a recoverable work log if you need to pause and resume a session.

Multi-File Navigation

Claude Code reads files when it needs them, but you can make it faster and more accurate by being explicit about context.

Reference files by path in your prompt:

"Update the rate limiter in src/middleware/rateLimit.ts. The Redis client is in src/db/redis.ts. The config is in config/server.ts."

Explicit file paths beat "find the rate limiter wherever it is." The agent will find it either way, but explicit paths mean it starts reading the right files immediately instead of exploring first.

Use @ mentions for targeted file references:

In interactive sessions, you can reference files with @filename.ts in your prompt. Claude Code will read that file as part of understanding your request. Useful when you want to ask questions about a specific file without running a full task.

Scope tasks to layers of your architecture:

Instead of "fix the billing bug," say "the bug is in the service layer, check src/services/billing.ts first." Claude Code can trace through the whole stack, but pointing it at the right layer first saves tokens and time.

How to Give Claude Code Better Instructions

The quality of Claude Code's output is almost entirely determined by the quality of your instructions. Better instructions, fewer revision cycles, less token spend.

A few patterns that consistently improve output:

Include an example of what you want. If you want code formatted a specific way, paste an existing function that looks right. Claude Code will match the pattern.

"Write the new endpoint following the same pattern as src/routes/users.ts:45-80. Same error handling, same response shape."

Name the antipatterns explicitly. If there is a way you do not want the problem solved, say so.

"Add pagination to the /items endpoint. Do not use cursor-based pagination — offset pagination is fine here. Do not add a new dependency for this."

Specify what you are not touching. Scope prevents unintended changes.

"Only modify src/routes/items.ts. Do not change the service layer or the database schema."

State your quality bar. If you want tests, say so. If you want a specific test coverage, specify it.

"Add tests for the three new endpoints. I want at least one happy path and one error case per endpoint."

For a full framework on writing instructions that work reliably, see How to Write Agent Instructions That Actually Work.

Recommended Settings for Solo Builders

A few settings worth configuring beyond the default:

Set your default model. Claude Sonnet is the right default. It is fast and accurate on standard coding tasks. Switch to Opus for architecture decisions, complex debugging, or when you need the model to reason across a large codebase with many constraints.

Keep sessions focused. Claude Code works best when it has one clear task per session. Opening Claude Code with "help me with my project" produces worse results than "add the Stripe webhook handler for payment_intent.succeeded, write tests, do not touch anything else."

Use git as your undo button. Before handing a complex task to Claude Code, commit your current work. If the agent goes in a direction you do not like, git checkout . resets everything. This removes the fear of letting the agent run autonomously.

Let it run tests automatically. If you have a test suite, add test commands to your auto-approve list. Claude Code that can run tests and fix its own errors is dramatically more useful than Claude Code that produces code and asks you to run the tests yourself.

When to Use Claude Code vs Your IDE

Claude Code is not a replacement for Cursor or Windsurf. They serve different modes of work.

Use your IDE for:

• In-line completion while you are actively writing code
• Quick, single-file edits
• Reading and navigating unfamiliar code
• Anything you want to stay in control of step-by-step

Use Claude Code for:

• Building a full feature end-to-end from a spec
• Refactoring across multiple files
• Writing tests for existing code
• Debugging complex issues where you want the agent to trace through the whole stack
• Automating your development workflow (scripts, CI tasks, release processes)

The highest-leverage setup: use Cursor or Windsurf as your daily driver, and route the heavy-lift tasks to Claude Code. You write the spec, Claude Code writes the feature. You review the result.

For a full comparison of the tools, see Cursor vs Windsurf vs Claude Code.

Common Mistakes

No CLAUDE.md. The agent has to infer everything from scratch. Sessions start slow and make more wrong assumptions.

One-line prompts for complex tasks. "Build a Stripe integration" produces worse results than a five-sentence prompt with the specific endpoints, the existing patterns to follow, and the constraints.

Not using /compact on long sessions. Token budget is real. A stale context window produces drifting, inconsistent output. Compact before you hit the wall.

Letting the agent push to production without a confirmation step. Claude Code can run git push and kubectl apply if you let it. Keep production operations in the confirm list.

Fighting the agent instead of improving the instructions. If Claude Code keeps producing output you do not want, the fix is almost always a better instruction, not more back-and-forth in the session.

The Actual Workflow

Here is what an effective Claude Code session looks like for a solo builder:

1. Make sure CLAUDE.md is up to date for this project
2. Commit current work (git commit) so you have a clean reset point
3. Write a precise task prompt: what to build, where, with what constraints, what done looks like
4. Let Claude Code run — resist the urge to interrupt unless it is going clearly wrong
5. Review the diff (git diff) before accepting changes
6. Run your test suite if Claude Code did not run it automatically
7. Commit the result

The loop takes fifteen to thirty minutes for a medium-complexity feature. The result is working, tested code you reviewed but did not write line by line.

At scale, this is how solo founders build products that should take a team. Not by writing faster. By delegating to an agent that does not get tired.

Related Guides

• Getting Started with AI Agents
• How to Write Agent Instructions That Actually Work
• Cursor vs Windsurf vs Claude Code
• Vibe Coding Tools: The New AI-Assisted Development Stack