Claude Code in Your Terminal: A Practical Workflow Guide for Developers

Most AI coding tools live inside your IDE as autocomplete engines. Claude Code is different. It's a terminal-first agent that reads your codebase, writes across multiple files, runs shell commands, manages git, and iterates until the job is done -- all through natural language conversation in your terminal.

If you've been using GitHub Copilot for inline suggestions or Cursor for project-aware editing, Claude Code occupies a fundamentally different space. It doesn't predict your next line of code. You tell it what you want done, and it goes and does it -- reading files it needs, writing changes, running tests, fixing failures, and committing the result.

I've been using Claude Code daily for the past several months. This guide covers the practical workflows, configuration tips, and real patterns that make it genuinely productive -- not the surface-level "install it and say hello" walkthrough.

What You'll Need

• A Claude subscription -- Claude Pro ($20/month) works, but Claude Max ($100/month for 5x usage or $200/month for 20x) is what most daily users end up on
• A terminal -- Bash or Zsh on macOS, Linux, or WSL on Windows
• A project to work on -- Claude Code shines on real codebases, not toy examples

Installation

The recommended install is the native binary (auto-updates in the background):

macOS / Linux / WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

After installation, navigate to your project and start a session:

cd your-project
claude

On first launch, you'll authenticate with your Claude account via browser. After that, you're in.

Verify everything is working:

claude doctor

The Core Workflow: Explore, Plan, Implement, Commit

Here's the workflow that actually works in practice. It's not "type a wish and hope for the best." It's a deliberate four-phase process:

Phase 1: Explore (Plan Mode)

Before touching any code, switch to Plan Mode by pressing Shift+Tab twice. In Plan Mode, Claude can only read files and think -- it cannot write anything. This is where you orient Claude to your codebase:

> Read the authentication module in src/auth/ and explain how sessions work.
> What middleware runs before each request? Show me the chain.
> How are database migrations handled in this project?

This is the most underrated step. Five minutes of exploration saves thirty minutes of Claude going in the wrong direction.

Phase 2: Plan (Still in Plan Mode)

Now ask Claude to design the approach:

> I want to add Google OAuth login. Based on what you've read, what files need
  to change? Create a plan.

Claude will produce a step-by-step plan. Here's the key move: press Ctrl+G to open that plan in your default text editor. Review it. Edit it. Remove steps that don't make sense. Add constraints Claude missed. Save and close -- Claude will use your edited version.

Phase 3: Implement (Normal Mode)

Press Shift+Tab to switch back to Normal Mode, then:

> Implement the OAuth flow from your plan. Write tests for the callback handler.
  Run the test suite and fix any failures.

Claude will now write code, run your tests, see failures, fix them, and iterate. You'll be prompted to approve file writes and shell commands (unless you switch to Auto-Accept mode with a single Shift+Tab).

Phase 4: Commit

> Commit with a descriptive message and push.

Or use the built-in skill:

> /commit

CLAUDE.md: The File That Makes Everything Work

CLAUDE.md is a markdown file that Claude reads automatically at the start of every session. It's your project's permanent context -- the things Claude needs to know but can't figure out by just reading source code.

Where to Put It

• ./CLAUDE.md in your project root -- check this into git. Your entire team benefits.
• ./CLAUDE.local.md in your project root -- gitignored, for personal preferences.
• ~/.claude/CLAUDE.md in your home directory -- applies to all your projects globally.

For monorepos, you can have CLAUDE.md files in subdirectories too. Claude loads them automatically when it works in that directory.

What to Include

The golden rule: for every line, ask "Would removing this cause Claude to make mistakes?" If not, cut it.

Here's a real example structure:

# Commands
- Dev server: `python manage.py runserver --settings=fundesk.settings.local_dev`
- Run tests: `pytest`
- Lint: `flake8`
- Import article: `python manage.py import_blog content/article.md --settings=fundesk.settings.local_dev`

# Code Style
- Use function-based views, not class-based
- All new API endpoints need token authentication
- Use django-environ for environment variables, never hardcode secrets

# Architecture
- Settings split across fundesk/settings/ (common.py, local_dev.py, local.py, prod.py)
- Article content supports both HTML and Markdown formats (article_content_format field)
- New articles should use markdown format with article-details-base-page.html template

# Git
- Branch naming: feature/short-description or fix/short-description
- Always run pytest before committing
- IMPORTANT: Never commit .env files or API keys

What NOT to Include

• Things Claude can figure out by reading the code (like "this is a Django project")
• Standard language conventions Claude already knows
• Long API documentation (link to docs with @docs/api-reference.md instead)
• Anything self-evident like "write clean code" or "use meaningful variable names"

The @import Trick

Keep CLAUDE.md lean and reference detailed files:

See @README.md for project overview.
Git workflow: @docs/git-instructions.md
API conventions: @docs/api-style-guide.md

Claude will load these files on demand when they become relevant.

Generate a Starter CLAUDE.md

If you're starting from scratch, run /init inside Claude Code. It analyzes your codebase and generates a starter file based on detected build systems, test frameworks, and code patterns.

Hooks: Automate the Boring Stuff

CLAUDE.md instructions are advisory -- Claude should follow them but might not always. Hooks are deterministic -- they guarantee an action happens at a specific point in Claude's workflow.

Configure hooks in .claude/settings.json or interactively with the /hooks command.

Auto-Format After Every Edit

This is the hook I use most. Every time Claude writes or edits a file, Prettier runs automatically:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$(echo $CLAUDE_TOOL_INPUT | jq -r '.file_path')\""
          }
        ]
      }
    ]
  }
}

Desktop Notification When Claude Needs Your Attention

When Claude finishes a long task or needs approval, get a macOS notification:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Block Edits to Protected Files

Prevent Claude from touching production configs or migration files:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "echo $CLAUDE_TOOL_INPUT | jq -r '.file_path' | grep -qE '(settings/prod\\.py|\\.env|migrations/)' && echo 'Protected file - not allowed' >&2 && exit 2 || exit 0"
          }
        ]
      }
    ]
  }
}

Exit code 2 blocks the action. The stderr message gets fed back to Claude so it knows why the action was blocked.

Re-Inject Context After Compaction

When your conversation gets long, Claude compacts the history and can lose important context. This hook re-injects critical reminders:

{
  "hooks": {
    "PreCompact": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Reminder: Always use pytest for testing. Never modify production settings directly.'"
          }
        ]
      }
    ]
  }
}

MCP: Connect Claude to Everything

MCP (Model Context Protocol) is an open standard that lets Claude Code connect to external tools, databases, and APIs. Think of it as USB-C for AI tools -- one protocol, hundreds of integrations.

Add MCP Servers

# Connect to GitHub
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# Connect to a PostgreSQL database (read-only recommended)
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
  --dsn "postgresql://readonly:pass@localhost:5432/myapp"

# Connect to Sentry for error tracking
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# Connect to Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp

What You Can Do With MCP Connected

Once your tools are connected, natural language just works:

> Check Sentry for the most common errors in the last 24 hours.
> Look at GitHub issue #142 and implement the fix.
> Query the users table to find accounts created this week.
> Find the relevant Notion doc about our API rate limiting policy.

Share MCP Config With Your Team

For personal MCP connections, they're stored in ~/.claude.json. To share with your team, create a .mcp.json in your project root:

{
  "mcpServers": {
    "db": {
      "command": "npx",
      "args": ["-y", "@bytebase/dbhub", "--dsn", "postgresql://readonly:pass@staging.db:5432/app"]
    }
  }
}

Check this into git. Now every team member running Claude Code in this project automatically has access to the staging database.

Manage MCP Servers

claude mcp list              # See all configured servers
claude mcp get github        # Details on a specific server
claude mcp remove github     # Remove a server

Context Management: The Most Important Skill

Claude Code has a ~200K token context window, but system prompts, CLAUDE.md, and MCP tool descriptions eat into that. In practice, you have about 140-150K tokens of conversation space. When it fills up, Claude's quality drops significantly.

This is the single most important thing to learn: managing context is more important than writing good prompts.

The /clear Habit

Use /clear between unrelated tasks. Finished debugging that API endpoint? /clear. Moving on to update the README? /clear. This is free and instant.

The /compact Command

When you're deep in a task and don't want to lose your conversation, use /compact to compress the history. You can even steer the summary:

/compact Focus on the database migration changes we've been making

Run this proactively at around 70% context usage, not when things are already degrading.

The Document-and-Clear Pattern

For complex multi-phase tasks, have Claude write its progress to a file before clearing:

> Write your current plan and all findings so far to PROGRESS.md

> /clear

> Read PROGRESS.md and continue from where we left off.

This gives you a clean context window with all the important knowledge preserved.

Use Subagents for Heavy Research

Instead of asking Claude to read 20 files in your main conversation (which bloats context), delegate:

> Use a subagent to investigate how our authentication system handles token
  refresh across all the files in src/auth/. Report back with findings.

The subagent runs in its own context window. Only the summary comes back to your main conversation.

Git Workflows That Actually Work

The One-Liner PR

For small changes, this is remarkably effective:

> Fix the typo in the error message in src/api/handlers.py line 42.
  Commit and create a PR.

The Full Feature Branch

> Create a branch called feature/email-notifications.
  Implement email notifications for new user signups using our existing
  email utility in src/utils/email.py. Write tests. Run the test suite.
  If everything passes, commit and create a PR with a clear description.

Resume From a PR

Coming back to review feedback on a PR you created earlier:

claude --from-pr 142

This loads the PR context so Claude knows exactly what changes were made and any review comments.

The /commit Skill

Instead of manually staging and committing, just use the built-in skill:

/commit

Claude analyzes staged and unstaged changes, drafts an appropriate commit message, and handles the git operations.

Permission Modes

Three modes, cycled with Shift+Tab:

For CI/CD or containerized environments where Claude runs unattended:

claude --dangerously-skip-permissions

Only use this inside containers with no internet access. Never on your development machine.

Session Management Tips

Resume Previous Work

claude --continue          # Resume the most recent session
claude --resume            # Pick from a list of recent sessions

Name Your Sessions

Inside Claude Code:

/rename auth-refactor

Then resume by name later:

claude --resume auth-refactor

Rewind Mistakes

Made a wrong turn? Press Esc twice or type /rewind to open the rewind menu. You can restore both the conversation state and file changes to any previous checkpoint.

Real-World Tips From Daily Use

1. Be Specific About Verification

Don't say: "Add a login endpoint."

Say: "Add a login endpoint at POST /api/auth/login. It should accept email and password, validate against the User model, and return a JWT. Write a test that verifies successful login and a test for invalid credentials. Run the tests."

The difference is Claude can verify its own work when you include test criteria.

2. Let Claude Interview You for Complex Features

For large features where requirements aren't fully clear:

> I want to add a subscription billing system. Interview me about the
  requirements -- ask about payment providers, plan types, billing cycles,
  trial periods, and edge cases. Keep asking until we've covered everything,
  then write a spec to SPEC.md.

Start a fresh session, then implement from the spec.

3. Use the Writer/Reviewer Pattern

Open two terminal sessions:

• Session A: "Implement the rate limiter for our API endpoints."
• Session B: "Review the rate limiter implementation in src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our patterns."

Two perspectives, minimal extra effort.

4. Don't Fight Context Limits

If Claude starts producing lower quality output, repeating itself, or forgetting things you said earlier -- your context is full. Don't push through. /clear and start fresh. Or /compact with specific guidance on what to preserve.

5. Start with Exploration, Even for "Simple" Tasks

Even when you think you know exactly what to change, start in Plan Mode and have Claude read the relevant files first. You'll catch dependencies and edge cases you didn't think of, and Claude's implementation will be better informed.

Pricing Reality Check

Most active developers I know end up on the Max 5x plan. The Pro plan runs out quickly once you start using Claude Code for real work -- a single complex task can consume significant capacity. The jump from $20 to $100 is steep, but if Claude Code saves you even a few hours per month, it pays for itself.

For API usage, Sonnet 4.6 at $3/$15 per million input/output tokens is the cost-effective workhorse. Opus 4.6 at $5/$25 per million tokens is for when you need the deepest reasoning.

Quick Reference: Keyboard Shortcuts

What's Next

Once you're comfortable with the core workflow:

• Build custom skills in .claude/skills/ for repetitive workflows specific to your project
• Set up Agent Teams (experimental) to have multiple Claude instances collaborate on complex tasks
• Connect MCP servers for your team's tools -- Slack, Jira, databases, monitoring
• Use headless mode (claude -p "...") to integrate Claude into your CI/CD pipeline and scripts

Claude Code isn't a better autocomplete. It's a different way of working with code entirely -- one where you focus on what needs to happen and why, while the agent handles the how. The developers getting the most out of it are the ones who've learned to think in terms of clear instructions and verification, not line-by-line editing.

Already set up an AI agent? Check out our OpenClaw Setup Guide to build a 24/7 personal AI assistant on EC2 for $10/month.