The Discuss-Then-Execute Workflow

The most important thing to understand about Claude Code is that it's not just something you give tasks to – it's a thinking partner with full access to your codebase. The best results come from treating it that way.

In practice, this means working in two phases:

1. Discuss: Brainstorm the approach. Ask Claude to reason about trade-offs, challenge your assumptions, explore the codebase, and identify potential issues. It can read every file in your project, so it often spots things you'd miss.
2. Execute: Once you've aligned on a direction, let Claude implement. It writes code, runs tests, and iterates on failures autonomously.

Skipping the first phase is the most common mistake people make. If you jump straight to "build this feature," Claude picks an approach without the benefit of discussion. Sometimes it picks well, but often it doesn't – and you end up spending more time undoing the work than the discussion would have taken.

Even experienced power users typically see around 85–90% of tasks fully achieved on the first attempt. That's remarkably effective, but it means roughly one in ten tasks needs course-correction. This is exactly why the discussion phase and verification loops exist – they catch the other 10–15% before it costs you time.

Some power users take this even further. Instead of using built-in plan mode, they ask Claude to write a plan to a markdown file (e.g. plan.md), then open it in their editor and add inline corrections directly into the document. They send Claude back to revise, repeat a few times, and only say "implement it all" once every detail is right. The plan file becomes shared state between you and Claude – a structured spec you can review holistically rather than a chat thread you'd have to scroll through.

Writing Effective Prompts

The quality of what Claude produces is directly related to the quality of what you give it. This is similar to working with a person – if you gave a colleague a one-sentence brief with no context, you wouldn't expect great results. The same applies here. A few principles that make a real difference:

• Be specific. Instead of "fix the bug", say "fix the login bug where users see a blank screen after entering wrong credentials – the issue is likely in src/auth/LoginForm.tsx." The more context you provide upfront, the fewer wrong turns Claude takes.
• Reference files directly. Use @filename to point Claude at specific files. This is faster and more reliable than asking it to search. Tab completion works.
• Provide external context. Paste URLs to GitHub issues, docs, or Stack Overflow answers directly and Claude will fetch and read them. You can also paste screenshots with Control-V (not Command-V on macOS).
• Break complex tasks into steps. Rather than "build a user profile system", try: "1. Create a database model for user profiles. 2. Add CRUD API endpoints. 3. Build a profile page component." Claude handles each step sequentially and can course-correct between them.
• State constraints explicitly. Things like "don't use external dependencies", "don't modify the existing API contract", or "use our existing Button component from src/components/ui."
• Ask Claude to ask you questions. For ambiguous tasks, try: "Before you start, ask me any clarifying questions about the requirements." This is where the collaborator side of Claude is most useful – it can identify gaps in the brief before writing any code.

Plan Mode

Plan mode is probably the single most impactful habit you can build. For anything non-trivial, always plan before you execute.

You activate it with Shift+Tab twice (or by typing /plan). This puts Claude in read-only mode – it can explore your codebase, search files, and fetch web content, but it can't modify anything. Claude produces a structured implementation plan, and you review it, challenge assumptions, and suggest alternatives. Only once you're satisfied do you exit plan mode (Shift+Tab again) to let it execute.

The Permission Mode Cycle

Shift+Tab cycles through three modes:

stateDiagram-v2
  Normal --> AutoAccept : Shift+Tab
  AutoAccept --> Plan : Shift+Tab
  Plan --> Normal : Shift+Tab

Most experienced users start in plan mode for new tasks, review the plan, then switch to auto-accept for execution. Normal mode is mainly useful when you're learning or want to watch each step closely.

Session Management

Two habits worth building:

• Use /clear aggressively. Every time you start something genuinely new, clear the conversation. Stale context causes mistakes and costs money.
• Use /compact when Claude has learned something valuable during a long session but the conversation has accumulated noise. It summarises the context while freeing up space.

A Typical Workflow

1. Start with /clear if you're beginning a new task.
2. Discuss the approach – describe what you want and ask Claude to think through the options.
3. Use plan mode (Shift+Tab twice) if the task is complex enough to warrant a structured plan.
4. Review and challenge – push back on anything that doesn't look right.
5. Switch to auto-accept and let Claude execute.
6. Commit frequently. Ask Claude to commit after each logical unit of work so you can revert if something goes wrong.

/clear

Add a dark mode toggle to the settings page. It should persist
the preference in localStorage and use our existing design tokens.
@src/components/Settings.tsx @src/styles/tokens.ts

Run the dev server and check for TypeScript errors. Then commit
this as "Add dark mode toggle with localStorage persistence".

Costs and Token Usage

Every interaction uses API tokens, and tokens cost money (on API billing) or count towards limits (on subscription). There are a few things worth keeping in mind:

• Long conversations cost more. Each message includes the full conversation history, so a 50-message session costs significantly more per message than a 5-message one.
• /clear saves money. Starting fresh for a new task means you're not paying for irrelevant context to be included in every request.
• /compact is cheaper than continuing. Summarising removes noise while keeping the valuable context.
• Model choice matters. Use Sonnet for most work, Haiku for quick mechanical tasks, and Opus when you need deep reasoning.

What to Take Away

The quality of Claude Code's output is mostly determined by how you use it. Discuss before you execute, plan before you implement, and manage your sessions well. These are habits that take a bit of effort to build, but they make a big difference to the results you get.