For developers who have the basics down and want a system that holds up under real work.

Claude Code Advanced Workflow: The Full Stack

For developers who have the basics down and want a system that holds up under real work.

The basics are simple: provide context, plan before big changes, keep sessions focused, run tests, and read the diff.

The advanced workflow is about making those habits repeatable. You are no longer just asking Claude Code to help with a task. You are designing a working system around planning, model choice, memory, review, hooks, skills, and parallel execution.

This is the full stack.

1. Use the Right Mode for the Right Work

Claude Code now exposes planning directly through /plan, and the current best-practice workflow is straightforward:

1. Explore the codebase. 2. Create a plan. 3. Implement against the plan. 4. Verify and commit.

The important move is separating exploration from implementation.

In plan mode, Claude can read files and reason about the approach without editing. That gives you a chance to catch the expensive mistake: building the wrong thing well.

Example:

/plan

Understand how billing invoices are created today.
Read the router, service, queue worker, and tests.
Do not edit files.
Return a plan for adding invoice cancellation.

Then review the plan. Only after the plan makes sense should you ask Claude to implement.

2. Pick Models by Job, Not Habit

Claude Code supports model aliases such as sonnet, opus, haiku, and best, plus effort levels on supported models. The practical split is:

Use Sonnet for most day-to-day coding.
Use Opus or higher effort for architecture, ambiguous planning, and difficult review.
Use Haiku-style fast paths for lightweight explanation or repetitive small tasks when available in your setup.

The point is not to worship one model. The point is to match the cognitive load.

Planning asks: "What should change, and what could go wrong?"

Implementation asks: "Apply this known change carefully."

Review asks: "What did we miss?"

Those are different jobs.

3. Keep Plans as Artifacts

For serious work, do not leave the plan trapped in chat. Save it as a Markdown file.

Good plans contain:

Goal: what should be true when the work is done.
Scope: files and subsystems likely to change.
Constraints: what must not change.
Tasks: small enough to verify independently.
Tests: exact commands or suites to run.
Rollback notes: what to undo if the approach fails.

Example structure:

# Plan: Invoice Cancellation

## Goal

Users can cancel pending invoices before payment capture.

## Constraints

- Do not change the public invoice creation API.
- Paid invoices must remain immutable.
- Existing webhook handling must still be idempotent.

## Tasks

- [ ] Add failing service tests for pending, paid, and missing invoices.
- [ ] Add `cancel_invoice` service method.
- [ ] Add route handler and authorization check.
- [ ] Run invoice service tests and webhook tests.

A plan file survives compaction, session switches, and review. It also gives your human teammates something concrete to inspect.

4. Use Skills for Repeatable Process

Skills are now the central way to extend Claude Code. They can live in project, personal, enterprise, or plugin locations. Each skill has a SKILL.md file, and it can include supporting files such as scripts, examples, templates, and reference docs.

Use a skill when the process matters:

Debugging a production issue
Reviewing a pull request
Migrating a framework or API
Running release checks
Producing a standard report
Applying a team-specific style guide

Modern skills can also define invocation behavior. For example, disable-model-invocation: true keeps a skill manual-only, which is useful for side-effecting workflows like deploys.

The discipline is simple: if you keep pasting the same playbook into chat, turn it into a skill.

5. Use Hooks for Deterministic Guard Rails

Instructions are advisory. Hooks are executable.

If something must happen every time, use a hook:

Run a formatter after file edits.
Block writes to sensitive files.
Log shell commands.
Prevent risky operations.
Validate prompts before Claude processes them.

Hooks are configured in JSON settings files such as .claude/settings.json or .claude/settings.local.json. They run at lifecycle events like PreToolUse, PostToolUse, UserPromptSubmit, Stop, and SessionStart.

The advanced habit is knowing which guard rail belongs where:

Put durable guidance in CLAUDE.md.
Put repeatable processes in skills.
Put non-negotiable automation in hooks.
Put one-off prompts in skills or legacy command files, depending on your setup.

6. Build Memory Deliberately

Claude Code has two persistent memory mechanisms:

CLAUDE.md files that you write.
Auto memory that Claude writes based on learned project patterns.

Use CLAUDE.md for stable instructions:

"Use pnpm, not npm."
"Integration tests require local Redis."
"Billing code must preserve idempotency keys."

Use auto memory as a helpful assistant, not a source of truth. Review it with /memory. Prune stale notes. Keep persistent context short and specific.

Large memory files reduce adherence. If a procedure grows too long, move it into a skill. If a rule only applies to certain files, use path-scoped rules.

7. Use Subagents and Agent Teams Carefully

Subagents are useful when a side task would flood the main session with noise. They run in their own context and return a summary.

Good subagent tasks:

Explore a large unfamiliar module.
Compare three possible implementations.
Review a diff for one kind of risk.
Search for all call sites of a pattern.

Agent teams go further: multiple Claude Code sessions coordinate as a team. As of the current docs, agent teams are experimental and disabled by default. They can be powerful, but they add coordination cost.

Use parallelism only when the work is truly independent.

A simple test:

Can each worker finish without editing the same files or depending on another worker's result?

If yes, parallelism may help.

If no, keep it sequential.

8. Review With a Fresh Context

Claude Code can review its own work, but the best review comes from a fresh pass.

Useful review prompts:

/review

Review the current diff for correctness, hidden coupling, missed edge cases, and tests that should exist but do not.

Or:

Read `plans/invoice-cancellation.md` and the current diff.
Tell me where the implementation diverges from the plan.

For bigger changes, use multiple review angles:

Correctness
Security
Maintainability
Test coverage
Consistency with existing patterns

Do not ask for "thoughts." Ask for findings.

9. Keep the Human in the Loop

The advanced workflow is not "let Claude do everything." It is knowing where your judgment matters most.

You should own:

The goal
The constraints
The acceptance criteria
The final diff review
The decision to merge

Claude Code can explore, draft, edit, test, summarize, and review. You remain responsible for taste, correctness, and risk.

The Workflow in One Pass

1. Start with /plan for anything non-trivial. 2. Ask Claude to explore before proposing changes. 3. Save the plan as a Markdown artifact. 4. Implement in focused tasks. 5. Use skills for recurring workflows. 6. Use hooks for non-negotiable automation. 7. Use CLAUDE.md and /memory for durable context. 8. Run tests and review the diff. 9. Use subagents only for truly independent side work.

That is the full stack: not one clever prompt, but a system that keeps the work aligned.

Sources

Part 2 of a seven-part series on using Claude Code efficiently.