I Stopped Using Claude Code Like a Chatbot: 14 Commands That Transformed My Workflow

Better prompts helped—but learning how to control the session changed everything

For months, I used Claude Code as if it were a normal chatbot.

I described a feature, pasted an error, waited for an answer, and continued adding messages to the same conversation.

At first, it worked well. But as the session became longer, the results started to decline.

Claude forgot earlier decisions. Responses became slower. Old errors consumed valuable context. I repeated instructions that I had already explained, and sometimes a simple change created unexpected modifications across the project.

The problem was not always the model.

The problem was how I was managing the session.

Claude Code is not simply a chatbot inside a terminal. It has commands for managing context, planning changes, configuring permissions, reviewing code, debugging problems, and recovering from mistakes.

Once I started using these commands as part of my normal engineering workflow, Claude Code became much more predictable and useful.

Here are the 14 commands that made the biggest difference.

Claude Code changes quickly. The commands in this article are based on the official documentation available in July 2026. Availability can depend on your installed version, platform, environment, and subscription. You can type / inside Claude Code to see the commands available to you. Claude Code commands reference

1. /init — Teach Claude About Your Project

When Claude enters a new repository, it can inspect the files, but it does not automatically understand every architectural decision or team convention.

Running:

/init

creates a starter CLAUDE.md file for the project.

This file can explain important information such as:

• The project architecture
  

• How to install dependencies
  

• How to run tests
  

• Coding conventions
  

• Important directories
  

• Commands Claude must run before completing work
  

• Files or patterns it should avoid modifying
  

For example:

# Project Guidelines

- Backend: Laravel 12
- Frontend: React with TypeScript
- Run backend tests with `php artisan test`
- Run frontend checks with `npm run lint`
- Use service classes for complex business logic
- Never modify production environment files
- Database changes must include reversible migrations

Without this context, you may repeat the same instructions in every conversation. With a good CLAUDE.md, Claude starts each task with a better understanding of the repository.

The important lesson is simple:

Do not begin a serious project by immediately asking Claude to write code. First, teach it how your project works.

2. /memory — Maintain the Instructions That Matter

/init creates the initial project guidance. /memory helps you review and maintain it.

/memory

Use it when you notice that you are repeatedly correcting the same behavior.

For example, if you keep telling Claude:

Do not put business logic inside controllers.

That instruction probably belongs in the project memory:

Controllers should validate input, call application services, and return
responses. Business logic belongs in service or domain classes.

Good memory contains information Claude cannot reliably discover from the code alone, such as:

• Team-specific conventions
  

• Architectural boundaries
  

• Known project risks
  

• Required verification commands
  

• Business rules that appear unusual but are intentional
  

Avoid filling memory with dependency lists or complete directory trees. Claude can inspect those when needed. Keep it focused on decisions, constraints, and lessons that prevent mistakes.

3. /plan — Understand the Change Before Editing Files

One of the most expensive mistakes with an AI coding assistant is allowing it to implement a large feature before it fully understands the problem.

Use:

/plan implement support for partial refunds

Claude will examine the relevant code and prepare an implementation approach before making the change.

This is especially useful for:

• Database migrations
  

• Authentication changes
  

• Large refactoring
  

• Payment integrations
  

• Queue architecture
  

• Multi-tenant behavior
  

• Features that affect backend and frontend code
  

A useful plan should identify:

• The files and components involved
  

• Existing behavior
  

• Proposed changes
  

• Database implications
  

• Backward-compatibility risks
  

• Testing strategy
  

• Possible edge cases
  

I now treat planning as a checkpoint. If the plan is wrong, correcting it costs a few minutes. If the implementation is already wrong, correcting it may cost hours.

4. /context — See What Is Consuming the Conversation

Claude Code has a limited context window. Your conversation, tool results, files, memory, and other loaded information all consume part of it.

Run:

/context

For more detail:

/context all

This command visualizes how the available context is being used and can identify unusually expensive tools or memory content.

It is useful when:

• Claude begins forgetting earlier requirements
  

• Responses become less focused
  

• The session has processed large logs
  

• You have opened many files
  

• You have been working on several unrelated problems
  

You should not wait until the session becomes unusable. Check context before beginning another large piece of work.

Think of context as working memory. More information is not always better. Relevant information is better.

5. /compact — Preserve Decisions and Remove Noise

Long conversations eventually accumulate noise:

• Failed attempts
  

• Repeated error messages
  

• Large command outputs
  

• Superseded decisions
  

• Unrelated questions
  

• Old implementation details
  

/compact summarizes the conversation and frees context while allowing you to continue the same task.

/compact

You can also tell it what the summary must preserve:

/compact Preserve the approved architecture, database decisions, unresolved
test failures, and the remaining implementation tasks.

That additional instruction is extremely valuable.

A generic summary may preserve the broad subject but lose a small decision that matters later. A focused compaction tells Claude which details are essential.

I use /compact after completing a meaningful phase, such as:

1. Investigation
   

2. Architecture
   

3. Implementation
   

4. Testing and review
   

This keeps the next phase focused without discarding the important history.

6. /clear — Start Fresh When the Task Changes

/compact is for continuing the same task with less context.

/clear is for starting a different task with empty conversation context.

/clear

You can name the previous conversation so it is easier to find later:

/clear payment-refactor

A common mistake is using one session for everything:

• Fixing authentication
  

• Investigating a slow report
  

• Building a React component
  

• Reviewing a migration
  

• Discussing deployment
  

The result is a context window full of unrelated assumptions.

Use a simple rule:

• Same goal, long conversation: /compact
  

• New goal: /clear
  

Project memory remains available, so starting a clean conversation does not mean Claude forgets your repository conventions.

7. /permissions — Control What Claude Can Do

Claude Code can read files, modify code, and run terminal commands. Permissions determine which actions are allowed automatically, which require approval, and which are denied.

Open the permissions interface with:

/permissions

This matters for both productivity and safety.

If every harmless command requires confirmation, you spend your time approving routine actions. If permissions are too broad, Claude may be allowed to perform operations you would prefer to review.

A practical configuration might:

• Allow reading source files
  

• Allow running tests and linters
  

• Allow safe Git inspection commands
  

• Ask before installing dependencies
  

• Ask before running migrations
  

• Deny access to sensitive credential files
  

• Deny destructive Git or filesystem operations
  

Good permissions reduce interruptions while keeping important boundaries under your control.

8. /mcp — Connect Claude to Real Project Tools

Developers often waste time copying information between systems:

• An issue from Jira
  

• An error from an observability platform
  

• A database schema
  

• A design from another application
  

• Documentation from an internal knowledge base
  

The Model Context Protocol allows Claude Code to connect to external tools and data sources.

Use:

/mcp

The command displays configured MCP servers and their connection status. Current versions also support actions such as reconnecting, enabling, and disabling servers.

For example:

/mcp reconnect sentry

MCP is useful because Claude can work with the source of information instead of depending entirely on what you manually paste into the conversation.

However, each connection should have the minimum permissions necessary. Access to more systems also creates more security and context-management responsibilities.

9. /doctor — Diagnose the Claude Code Environment

Sometimes the problem is not your application. It is the Claude Code setup itself.

Run:

/doctor

The command checks for issues such as:

• Installation problems
  

• Duplicate or outdated installations
  

• Invalid settings
  

• PATH problems
  

• Slow hooks
  

• Unused integrations
  

• Excessive context consumed by configuration
  

This is the first command I would use when Claude Code behaves unexpectedly across multiple projects.

For example, if tools fail to start, settings are ignored, or the command behaves differently between terminals, /doctor can help distinguish an environment problem from a project problem.

Debugging becomes faster when you first identify which system is actually failing.

10. /debug — Investigate Claude Code Runtime Problems

/doctor checks the general setup. /debug is intended for runtime problems inside the current session.

/debug

You can provide a focused description:

/debug The test command hangs after database seeding

This enables debug logging for the session and helps analyze the related diagnostic information.

Use it when:

• A tool call unexpectedly fails
  

• A command hangs
  

• An integration disconnects
  

• Claude repeatedly receives incorrect tool results
  

• The same operation behaves inconsistently
  

The description matters. “Something is broken” gives the debugger a very wide search area. A clear symptom, expected result, and reproduction step produce a more useful investigation.

11. /diff — Review What Actually Changed

Never rely only on Claude’s explanation of what it changed.

Inspect the code itself.

/diff

This opens an interactive viewer for uncommitted changes and per-turn diffs.

Look for:

• Unrelated modifications
  

• Removed validation
  

• Accidental formatting changes
  

• Missing error handling
  

• Changed public interfaces
  

• Debugging code left behind
  

• Files modified outside the agreed plan
  

This command creates an important separation between implementation and acceptance.

Claude may say:

The feature is complete.

The diff answers the more important question:

What exactly changed in my repository?

Trust the change only after reviewing the evidence.

12. /code-review — Ask for a Dedicated Review Pass

The agent that implemented a feature should not be the only one evaluating it.

Run:

/code-review

You can choose an effort level:

/code-review high

Current versions can also apply accepted fixes:

/code-review high --fix

A dedicated review can find issues such as:

• Incorrect edge-case handling
  

• Concurrency problems
  

• Security weaknesses
  

• Missing authorization
  

• Performance regressions
  

• Unnecessary complexity
  

• Incomplete cleanup
  

Review works best when the implementation requirements are specific. Tell Claude about the expected behavior and the risks that deserve extra attention.

For example:

/code-review high

Focus on authorization, transaction boundaries, duplicate payment prevention,
and backward compatibility with existing API clients.

Generating code and reviewing code are different mental tasks. Treat them as separate workflow stages.

13. /verify — Prove the Feature Works

Passing tests is useful, but it does not always prove the application works correctly.

A frontend can compile while displaying a broken layout. An API test can pass while the real authentication flow fails. A Laravel route can exist while the complete user journey is unusable.

Run:

/verify

This asks Claude to build and run the project, then observe the actual behavior instead of relying only on static checks.

Verification should answer questions such as:

• Does the application start?
  

• Can the user complete the workflow?
  

• Does the UI display the expected state?
  

• Does the API return the correct response?
  

• Are errors handled properly?
  

• Did the change break an existing path?
  

The difference is important:

Tests passed.

is not the same as:

The feature works.

The strongest workflow uses both automated tests and behavioral verification.

14. /rewind — Recover Without Manually Undoing Everything

AI-assisted development involves experimentation. Some approaches will be wrong, and occasionally a change will move the conversation and code in an unhelpful direction.

Use:

/rewind

This allows you to return the conversation, code, or both to a previous checkpoint. It can also summarize from a selected point.

This is much safer than asking:

Please undo everything you just did.

That instruction is ambiguous. Claude must infer which files and modifications belong to “everything,” and it may miss part of the change.

/rewind gives you a defined recovery point.

I find it especially useful after:

• An unsuccessful refactor
  

• A misunderstood requirement
  

• An experiment that changed many files
  

• A migration approach that proved unsafe
  

• A conversation that followed the wrong assumption
  

The confidence to experiment comes partly from knowing you have a reliable way back.

My Current Claude Code Workflow

These commands are most valuable when combined into a repeatable process.

Starting a new repository

/init
/memory
/permissions

Beginning a large feature

/clear
/plan implement the feature

During implementation

/context
/compact Preserve the approved plan and remaining tasks

When Claude Code behaves unexpectedly

/doctor
/debug Describe the exact problem

Before accepting the work

/diff
/code-review high
/verify

When an approach fails

/rewind

This workflow changes Claude Code from an answer generator into a controlled engineering process.

The Biggest Lesson

Better prompting matters, but session management matters just as much.

You can write an excellent prompt inside a poorly managed session and still receive a weak result. Claude may be working with irrelevant context, outdated decisions, unclear permissions, or an incorrect understanding of the project.

The commands in this article solve different parts of that problem:

• /init and /memory provide durable project knowledge.
  

• /plan reduces premature implementation.
  

• /context, /compact, and /clear keep conversations focused.
  

• /permissions and /mcp control access to tools.
  

• /doctor and /debug diagnose problems.
  

• /diff, /code-review, and /verify create quality gates.
  

• /rewind makes experimentation recoverable.
  

The goal is not to memorize every available command.

The goal is to stop treating Claude Code like a chat window and start treating it like an engineering environment.

Once I made that shift, the quality of the results improved—but more importantly, the workflow became easier to understand, review, and trust.

Suggested Medium tags: Claude Code, AI Coding, Software Development, Developer Productivity, Artificial Intelligence

The cover image was ne