Getting Real Work Out of Claude Code: A Practical Workflow Guide

Claude Code is an agentic coding tool: it reads a repo, plans, edits files, runs commands, executes tests, and calls external tools. It is terminal-based but editor-agnostic, and works over SSH and inside tmux.

The single idea worth internalizing:

Model quality sets the ceiling. Context, tools, feedback, and permission settings decide where you actually land.

Five levers, in rough order of impact:

1. Start with questions, not edits

Before asking for changes, ask about the repo. It is zero-risk and it teaches you how much Claude infers on its own.

How does authentication work here? Identify entry points, middleware, models, and tests.
Why does this function take so many arguments? Check git history for when each was added.
Which tests cover this feature?

Claude can go past text search into call sites, tests, commit history, and linked issues. This is the fastest path through unfamiliar or legacy code.

2. Give full context in the first turn

Short prompts are the most common self-inflicted problem. State the goal, the constraints, and how you will judge the result:

Goal: add rate limiting to /api/login
Constraints: don't touch the DB schema, keep the auth flow unchanged, use the existing Redis
Acceptance: unit tests pass, 429 returned after 5 attempts in 60s

If Claude asks a lot of clarifying questions or drifts, the brief was usually incomplete. Voice dictation helps here mostly because spoken instructions carry more context than typed ones.

3. Plan before large changes

Enter plan mode with Shift+Tab, iterate on the plan, then switch to execution. Two questions decide how much process a task needs:

In table form:

Planning catches misread requirements before they become 400 lines of wrong code.

4. Verification is the highest-leverage investment

Without feedback, Claude is predicting. With feedback, it iterates. Quality improvements of 2x to 3x are typical when a robust verification loop exists.

Sources of feedback, in rough order of setup cost: type checks and linters, unit and integration tests, build commands, application logs and API responses, browser screenshots, simulators.

For web UI, the Claude in Chrome extension provides a capable, token-efficient solution. Hand it a mock-up, let it launch the app, take a screenshot, compare, and revise.

The core design question for any workflow: how will Claude know whether the result is correct?

5. Persist context in CLAUDE.md

Loaded at session start. Include information that would otherwise be retyped every session:

# Project overview
Web application and API.

## Directories
- `src/api`: handlers
- `src/services`: business logic
- `tests`: integration tests

## Commands
- Test: `npm test`
- Single test: `npm test -- <name>`
- Typecheck: `npm run typecheck`

## Rules
- Keep handlers thin, logic in services
- Add a test for every bug fix
- Do not hand-edit generated files

Key principles for effective memory configuration:

• Keep it under roughly 200 lines. Memory consumes context every turn, and long files reduce rule adherence.
• Layer configuration: enterprise policy, user (~/.claude/CLAUDE.md), project (./CLAUDE.md), local, and nested subdirectory files loaded only when Claude reads files in that subtree.
• Commit the project file. Keep personal preferences in user memory, local machine details in a gitignored file.
• # prefix adds a memory mid-session and prompts for which file to save it to. Use it when Claude repeats a mistake.
• Auto memory maintains notes from corrections in ~/.claude/projects/<proj>/memory/. Check /memory to view active entries.
• /init bootstraps a first draft from your codebase.

Add a rule when it reflects a true project invariant, not after a single isolated mistake.

6. Tools beyond the shell

Claude infers standard git workflows without procedural prompting. A simple instruction like “Commit, push, open a PR” is usually sufficient.

For internal CLIs, direct the model to read the help output:

Use the `deploy-tool` CLI for this. Run `deploy-tool --help` first.

Document the CLI pattern in CLAUDE.md so it does not need to be rediscovered in future sessions.

MCP servers connect Claude to issue trackers, monitoring, internal databases, documentation, and design tools. The main value is access to the same information sources the team already uses.

7. Turn repeated prompts into slash commands

Workflows performed multiple times a day belong in .claude/commands/, checked into git:

/review-pr, /commit-push-pr, /prepare-release, /label-issue, /run-security-check

Commands can embed inline bash to precompute context and cut a round trip. Configure once, share with the team.

Subagents protect the main context window. Use a subagent when you want the result of a subtask without its intermediate steps polluting your main session.

8. Permission modes

Shift+Tab cycles modes. The default configuration includes:

Auto mode serves as the recommended replacement for --dangerously-skip-permissions. It auto-blocks operations like curl | bash, force-pushing to main, production deployments, and mass deletions. It includes a safety circuit breaker that reverts back to manual prompting after repeated blocked actions.

Start restricted on complex or unclear tasks, loosening permissions once direction is confirmed.

9. Shortcuts worth muscle memory

Check ? on an empty prompt to confirm shortcuts for your installed version.

10. Headless use

Executing claude -p (or --print) transforms the tool into a composable Unix utility with JSON or streaming output and per-invocation tool restrictions:

some-command | claude -p "Analyze this output and identify the likely failure"

some-command | claude -p "Return findings as JSON" | jq '.findings'

Useful for CI failure triage, log summarization, diff review, issue classification, and release note generation.

11. Parallel sessions

Multiple terminals, tmux sessions, or git worktrees provide isolated workspaces for concurrent agents. Avoid having two active agents share a single working tree.

Parallelism pays off when each task has clear boundaries and independent verification loops.

Common failure modes

Adoption path

1. Codebase Q&A and onboarding
2. Small bounded changes with existing tests
3. Planning required for larger features
4. Short shared CLAUDE.md
5. Slash commands and MCP config in the repo
6. Automated verification loops
7. Headless use in CI and scripts
8. Parallel sessions on isolated worktrees

Each stage should be stabilized before adopting subsequent automation levels.

Summary Principles

1. Verification is Key: Quality relies heavily on feedback loops (typechecks, tests, logs, or browser screenshots).
2. Context Management: Maintain CLAUDE.md under 200 lines to ensure high instruction adherence.
3. Controlled Autonomy: Match permission modes to task risk, starting in plan mode for complex tasks and relaxing permissions as confidence grows.