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

Sun, 02 Aug 2026 00:00:00 +0000

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:

Lever	What it means	Cost to set up
Verification	Claude can check its own output (tests, types, screenshots, logs)	Medium, highest payoff
Context	Architecture, commands, conventions in `CLAUDE.md`	Low
Planning	Investigate and propose before editing	Free
Tools	Shell, git, internal CLIs, MCP servers, browser	Low to medium
Controlled autonomy	Permission modes matched to task risk	Low

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:

Task	Approach
Rename, small fix	Implement directly
Bug with a known test	Implement and verify
Cross-cutting feature	Plan first, approve, then implement
Architectural change	Explore, plan with trade-offs, approve, implement, validate

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:

Mode	Behavior
`default` (Manual)	Prompts for edits and commands
`acceptEdits`	File edits auto-approved, commands still prompt
`plan`	Investigates and proposes, no edits
`auto` (if enabled)	A classifier decides per action; reads, edits, and safe commands pass, risky ones block
`bypassPermissions`	Sandboxes and containers only

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.

Key	Function
`Shift+Tab`	Cycle permission modes
`Esc`	Interrupt mid-turn, retain progress, redirect agent
`Esc Esc`	Clear input draft, or open the rewind menu on empty prompt
`Ctrl+O`	Toggle transcript viewer with full tool detail
`Ctrl+R`	Reverse search prompt history
`Ctrl+B`	Background a running command (twice in tmux)
`Ctrl+T`	Toggle task checklist
`#`	Add a memory
`@`	Reference a file, directory, or URL
`!`	Shell mode: runs locally, output enters context
`/btw`	Ask a side question that bypasses conversation history

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

Mistake	Fix
Single giant implementation prompt	Explore and plan first
Missing feedback loops	Add tests, types, build, or browser checks
Re-explaining project architecture	Maintain `CLAUDE.md`, use `#`
Unshared local configurations	Commit commands, MCP configs, and permissions
Approving every trivial edit	Switch to `acceptEdits` or `auto` once on track
Granting full autonomy initially	Transition after the plan is confirmed
Using as a basic search engine	Request an engineering process, not a simple lookup

Adoption path

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

Each stage should be stabilized before adopting subsequent automation levels.

Summary Principles

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

Developer Tools | Yassir Boulaamane