9 Claude Code Features
That Changed How I Work

When Claude Code first dropped, my workflow was embarrassingly simple: type a prompt, wait for output, read it, type another prompt. Repeat until the feature was done. It felt fast compared to doing it manually — but I was still the bottleneck. Everything went through me, one task at a time.

The shift happened when I started reading the actual documentation instead of just vibing with the tool. What I found underneath the surface was genuinely shocking — a full orchestration system for autonomous work. This post breaks down every feature that changed my workflow, explains what it is, why it matters, and how to actually use it. Do your own research after reading this — your mileage will vary, and the best setup is the one that fits how you think.

1. Git Worktrees — True Parallelism

This is the single biggest unlock in the entire list. Most developers use Claude Code on one branch at a time — finish a task, commit, start another. Git worktrees blow that model wide open.

The reason this matters for Claude Code is that each Claude instance operates in its own working directory. If you give three Claude instances three separate worktrees, they work on three different branches simultaneously — none of them can step on each other's changes because they're literally in different folders on disk.

# Create three worktrees for three features
git worktree add ../project-auth    feature/auth-revamp
git worktree add ../project-payment feature/payment-flow
git worktree add ../project-perf   feature/perf-audit

# Now open Claude Code in each directory
# (three separate terminal tabs / windows)
cd ../project-auth    && claude
cd ../project-payment && claude
cd ../project-perf    && claude

# Three Claude instances, three branches, zero conflicts

In practice, I now start my mornings by spinning up worktrees for everything on my plate that day, launching Claude in each one, and then checking back in as each finishes. It's the closest I've come to having a team of developers. You do the architecture thinking, Claude does the execution — all in parallel.

2. Background Subagents — Fire and Forget

The single most annoying part of early AI-assisted coding was the waiting. You send a prompt, and then you sit there watching tokens stream in, afraid to context-switch because you might miss something or need to steer it.

Background subagents solve this completely. You launch a task, and Claude runs it on its own in the background — writing files, running commands, iterating on errors. When it's done, it notifies you. You get a full summary of what happened without having to babysit the process.

The mental model shift here is significant. You stop thinking "let me ask Claude to do this" and start thinking "let me assign this to Claude and come back." It's the difference between being a developer and being an engineering manager. You're not in every PR — you're setting direction and reviewing outcomes.

3. Voice Input — Talk to Claude Anywhere

This sounds like a gimmick until you actually start using it. Claude Code supports voice input via a local Whisper model — meaning transcription happens on-device with no latency, no network dependency, and it even works offline.

I use this most on commutes and when my hands are occupied. The killer use case: whispering into my earphones on a flight. I've shipped meaningful architectural decisions at 35,000 feet while everyone else was watching movies. The local model means I'm not worried about sending work conversations to an external API.

There's also a cognitive benefit that surprised me: spoken instructions tend to be more natural and context-rich than typed ones. When I'm typing I tend to be terse. When I'm speaking I naturally give more background, more nuance, more "and the reason I want it this way is…" — which makes Claude's output noticeably better.

4. Context Hygiene — The Milk Principle

Context is milk. It has a freshness window, and once it goes bad, everything it touches gets worse. This is the least glamorous item on this list and the one that has probably helped my output quality the most.

The two habits that made the biggest difference:

# Compact the current context before it bloats
/compact

# Start a totally fresh session
/clear

# Check how much context you've used
/status

5. Skills Over System Prompt

Most people who use Claude Code with a custom setup have a single giant CLAUDE.md file — a system prompt that contains everything Claude needs to know about the project, the stack, the conventions, the team preferences. This works, but it has a serious cost: that entire file burns context tokens on every single request, even when most of it is irrelevant.

The better pattern is on-demand skills. Instead of one monolithic file, you create a /skills directory with individual Markdown files for specific domains — one for the design system, one for the API conventions, one for the testing setup. Claude reads the relevant skill file only when working in that area.

.
├── CLAUDE.md              # Thin: project overview + skill index only
├── skills/
│   ├── design-system.md   # Loaded when touching UI components
│   ├── api-conventions.md # Loaded when working on endpoints
│   ├── testing-setup.md   # Loaded when writing tests
│   └── deploy-process.md  # Loaded when shipping
└── src/

Your main CLAUDE.md becomes a lightweight index: project overview, tech stack, and a list of which skill files exist and when to use them. Claude reads the right skill file at the start of the relevant task and ignores the rest. The result: roughly half the baseline context usage, with more focused and accurate output on specialized tasks.

6. Docker Containers — Sandbox Everything Risky

Claude Code can execute commands. It can install packages, modify config files, run scripts, and delete things. In a development environment, that's mostly fine — version control protects you. But for overnight tasks, scripts that touch production artifacts, or anything involving destructive operations, you want a container boundary between Claude and your actual filesystem.

FROM node:20-slim

# Install Claude Code globally
RUN npm install -g @anthropic-ai/claude-code

# Set working directory
WORKDIR /workspace

# Mount your project here at runtime:
# docker run -v $(pwd):/workspace -it claude-sandbox claude

I use this for two types of tasks: anything that runs overnight (migrations, large refactors, batch processing scripts), and anything that involves commands I haven't fully vetted. The container is the cage — Claude can run wild inside it, and my actual machine is untouched. If something goes catastrophically wrong, I just delete the container.

7. Write-Test Cycle — Full Autonomy Loop

The write-test cycle is the closest thing to a truly autonomous coding loop that currently exists. The idea is simple: instead of asking Claude to just write the code, you give it both the target code file and the test file at the same time. Claude writes the implementation, runs the tests, reads the failures, fixes the code, re-runs — and keeps iterating until the tests pass.

No human in the loop. No "does this look right?" back-and-forth. Just: here's the spec (the test), here's where the code should go — make them agree.

Implement the AuthService class in src/auth.ts so that all
tests in src/auth.test.ts pass. Run the test suite after
each change and iterate until everything is green.
Do not modify the test file.

The key constraint is the last line: do not modify the test file. Without that guardrail, Claude will sometimes take the path of least resistance and change the tests to match the code. With it, the tests become an immutable specification that Claude must satisfy — which is exactly what you want.

8. Conversation Cloning — Fork Your Sessions

This one is subtle but wildly useful in specific situations. Conversation cloning lets you fork an existing Claude session at any point and explore two different approaches simultaneously, keeping both branches alive. You pick the winner, or learn something from both.

The most common use case: you've spent 20 messages establishing deep context about a complex system, and now you want to try two fundamentally different architectural approaches. Without cloning, you have to pick one and commit. With cloning, you fork the session, try Approach A in one branch and Approach B in the other, then compare the results.

I also use this for code review. Fork the session, ask one branch to critique the implementation harshly, ask the other to suggest a completely different approach. Reading both responses together gives you a much richer picture than a single linear conversation.

9. Automation of Automation — The Endgame

Everything above is a feature. This is a philosophy — and it's where the compounding really starts.

The idea is to use Claude Code to build the scripts, templates, and tooling that make future Claude Code sessions faster and more capable. You're not just automating tasks — you're automating the automation infrastructure itself.

The compounding effect here is real. Every automation you build with Claude makes the next automation faster to build. Every skill file you generate makes Claude more accurate in that domain. Every workflow script you write reduces the friction for future parallel work. The ceiling keeps rising the more you invest in the infrastructure layer.

How to Start: A Practical Ramp

If you're reading this and feeling overwhelmed, here's the honest progression I'd recommend. Don't try to implement all nine things at once — that's how you end up with a complex setup you don't understand and abandoned after a week.