Claude Code in Practice (Part 1): From Launch Modes to Concurrent Workflows

Introduction

If you've already picked up Claude Code (CC for short) but still use it as a one-off question answerer, this article might change how you think about it.

This is Part 1 of a practical experience series, built from lessons learned — and pitfalls hit — during day-to-day development. It covers flexible launch modes, project-level CLAUDE.md configuration, choosing the right conversation mode for the right situation, and what to watch out for when running multiple tasks in parallel.

No fluff, just what's useful. If even one thing here changes how you work, it's worth it.

---

Advanced Launch: Two Underrated Startup Modes

The Ralph Loop: Let CC Iterate Autonomously to Completion

Named after Ralph Wiggum from The Simpsons — not the sharpest tool in the shed, but relentlessly optimistic and never gives up.

The core idea of the Ralph Loop is simple: have CC repeatedly execute, check progress, and advance — all on its own — until the task is done.

When to use it: tasks that can be broken into discrete steps, each with a clear completion signal, where you don't need to make decisions at every step.

#!/bin/bash

# Maximum iterations to prevent infinite runs
MAX_ITERATIONS=10
PROMPT_FILE="prompt.md"       # Prompt file fed to the AI on each iteration
COMPLETE_SIGNAL="COMPLETE"    # Signal that marks task completion

for i in $(seq 1 $MAX_ITERATIONS); do
  echo "=== Iteration $i ==="

  # Call Claude Code, feeding in the prompt file
  OUTPUT=$(claude --print --dangerously-skip-permissions < "$PROMPT_FILE")

  echo "$OUTPUT"

  # Detect completion signal and exit early
  if echo "$OUTPUT" | grep -q "<promise>$COMPLETE_SIGNAL</promise>"; then
    echo "✅ Task complete, exiting loop (iteration $i)"
    exit 0
  fi

  echo "--- Not done yet, continuing to next iteration ---"
done

echo "⚠️ Reached maximum iterations ($MAX_ITERATIONS), stopping"

Pair this script with a prompt.md that drives CC's behavior:

You are an autonomous software engineer working on this codebase.

## Your Task
Read `PRD.md`, find **one** incomplete task, implement it, then mark it as done.

## Rules
1. Read `PRD.md` and find the first uncompleted task (marked `[ ]`)
2. Implement the feature fully, including any necessary tests
3. Run the tests and make sure they pass
4. Mark the task as `[x]` in `PRD.md`
5. Commit the changes with a clear git commit message
6. Check `PRD.md` — if **all tasks are complete** (no remaining `[ ]`), output:
   <promise>COMPLETE</promise>
   then stop.
7. If tasks remain, end the session without outputting COMPLETE; wait for the next iteration

## Key Constraints
- Do **one** task per iteration — don't get greedy
- If there are compile errors or test failures, fix them before committing
- Always use git history to understand what the previous iteration did

And a sample PRD.md:

# Project Requirements

## Feature List

- [ ] Implement user registration API (POST /api/register)
- [ ] Implement user login API (POST /api/login), returning JWT
- [ ] Implement auth middleware to validate JWT
- [ ] Write integration tests for all three endpoints above
- [ ] Add a README explaining how to run locally

Once running, CC advances through tasks one by one, ticking off each [x], until everything is done and it emits the COMPLETE signal. The loop script catches it and exits.

Your only job: write a solid PRD, then go grab a coffee.

---

claude -p: Treating CC as an API

Sometimes you don't need a back-and-forth conversation — you just want to feed in a prompt and get a result. claude --print (shorthand: -p) is exactly for that.

echo "Analyze the time complexity of this code: ..." | claude -p

This turns CC into a command-line black box: prompt goes in, result comes out, one shot, no interaction needed.

Real-world use case: a bug analysis tool in Jira calls a CC skill directly to analyze logs, without anyone manually opening a terminal.

If you need to follow up on a previous call, add the -c flag:

# First call
echo "Analyze this log file for me" | claude -p

# Continue the previous session (-c = continue, -p = print mode)
echo "Based on that analysis, what are the fix suggestions?" | claude -c -p

-c restores the previous conversation's context, keeping multi-call sequences coherent.

---

CLAUDE.md: Your Project's Owner's Manual

When you pick up a new codebase, your first command should be /init.

CC will read through the project's documentation and code structure, form a comprehensive understanding of the codebase, and write it into CLAUDE.md. This file is CC's "onboarding document" — it's read at the start of every conversation.

A good CLAUDE.md should include:

# Project Overview

## Tech Stack
- Language: Kotlin + Java
- Build Tool: Gradle
- Framework: Android AAOS (Android Automotive OS)

## Directory Structure
- `app/` - Main application module
- `libs/` - Shared libraries
- `scripts/` - Build scripts

## Common Commands
- Build: `./gradlew assembleDebug`
- Test: `./gradlew test`
- Lint: `./gradlew lint`

## Important Notes
- Do not directly modify files under `auto-generated/`
- All commits must pass lint checks

Think of CLAUDE.md as a handover document for a new teammate — the clearer it is, the more accurate CC's understanding will be, and the better every future conversation will go.

---

Three Conversation Modes: Picking the Right One Matters

CC has three modes, each representing a different level of trust and a different use case. Switch between them with Shift + Tab.

Plan Mode: The Strategist — Plans Everything, Touches Nothing

"Strategy before action."

In Plan Mode, CC will not modify a single file in your project. It only thinks and plans; nothing gets executed until you say so.

When to use it: unclear requirements, complex logic, changes that might ripple across multiple modules.

How it works in practice:

1. Switch to Plan Mode (Shift + Tab)
2. Hand CC your requirements and ask it to build an implementation plan
3. CC generates a plan file (open it directly in your IDE with Ctrl + G)
4. Review the plan carefully, edit it manually if needed
5. Switch back to an execution mode and let CC follow the plan

Don't run Plan Mode for trivial changes like UI tweaks or text translations — it'll just slow you down. Reserve it for tasks where "getting it wrong is expensive to fix."

A workflow tip from Boris (CC's creator):

First have Claude understand the code and generate a plan in Plan Mode, then use a second Claude session to audit that plan for soundness — only then start coding.

Two CC sessions cross-checking each other significantly reduces the chance of going in the wrong direction.

Auto-accept Edits Mode: Full Trust, Full Speed

Once the plan is confirmed in Plan Mode, switch to Auto-accept Edits. CC's output is written directly to your files — no approval needed for each change.

When to use it: plan is clear, risk is manageable, you want CC to move fast.

Default Mode: Cautious, Step-by-Step Review

Every file change requires your explicit approval.

When to use it: changes to core or complex logic — worth reviewing the diff before authorizing the write, to prevent CC from overstepping into areas it doesn't fully understand.

Mode Comparison

Mode	Code Changes	Best For
Plan Mode	❌ Plans only	Requirements analysis, complex feature planning
Auto-accept Edits	✅ Auto-writes	Clear plan in place, low-risk changes
Default Mode	⚠️ Confirm each	Core logic, high-risk changes

---

Typical Workflow

With the three modes in mind, here's a recommended workflow structure:

Receive requirement
        │
        ▼
Plan Mode: Understand code → Generate plan
        │
        ▼
Review plan (manually edit if needed)
        │
        ▼
Auto-accept Edits Mode: Execute implementation
        │
        ▼
Default Mode: Review critical changes
        │
        ▼
Test & verify → Commit

Key point: don't skip the Plan phase. A lot of people jump straight to having CC write code, then find the direction is wrong and spend more time rewriting large chunks of logic. Planning upfront is almost always faster in total.

---

Concurrent Operations: Multiple Windows, Multiple Tasks

CC has no single-thread constraint like the human brain — you can run different tasks in separate terminals simultaneously.

Example: Terminal A develops Feature A, Terminal B develops Feature B, both running in parallel without interfering with each other.

Two common pain points come up in practice:

Issue 1: Window Names Get Confusing

CC auto-generates window names based on conversation content, and they're not always what you'd expect — and they can change as the conversation evolves.

Fix: use /rename to manually set the window name:

/rename feature-a-ambient-lighting

With descriptive names, you won't lose track no matter how many windows you have open.

Issue 2: Getting Notified When CC Finishes

When running tasks concurrently, you can't stare at every window waiting for results. Configure CC to send you a notification when it needs attention.

macOS notification config (add to ~/.claude/settings.json):

{
  "hooks": {
    "Notification": [
      {
        "matcher": "permission_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Your confirmation is needed\" with title \"Claude Code\" sound name \"Ping\"'"
          }
        ]
      },
      {
        "matcher": "idle_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Waiting for your input\" with title \"Claude Code\" sound name \"Glass\"'"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Task complete\" with title \"Claude Code\" sound name \"Hero\"'"
          }
        ]
      }
    ]
  }
}

Ubuntu requires additional Python scripts. Add this to settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/anaconda3/bin/python3 ~/.claude/hooks/hook_stop_notification.py"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/anaconda3/bin/python3 ~/.claude/hooks/hook_notification_notification.py"
          }
        ]
      }
    ]
  }
}

Once configured, CC will send a notification whenever it finishes a task, needs confirmation, or is waiting for input. Go focus on something else — CC will come find you.

Bonus: The Terminal Boris (CC's Creator) Actually Uses

Ghostty

• Arbitrary window splitting (horizontal, vertical, any combination)
• Theme customization
• Keybinding customization

When running multiple CC windows in parallel, Ghostty's split-pane layout is excellent — all your CC terminals visible at once.

---

Summary

Part 1 covered several CC capabilities that are easy to underestimate:

1. The Ralph Loop: write a solid PRD, let CC iterate autonomously — ideal when tasks can be clearly decomposed
2. claude -p mode: treat CC as an API, perfect for external program integration
3. CLAUDE.md: the project's owner's manual; maintain it after /init, it's the foundation of CC's project understanding
4. Three conversation modes: Plan → Auto-accept → Default, switch based on task risk
5. Concurrent operations: multiple windows running in parallel, notifications configured, CC comes to you when it's done

These topics sit at the "how to work with CC as an engineering tool" level. Part 2 goes deeper into memory, rules, permission management, and shortcuts — the configuration layer that makes CC truly fit your personal and team working style.