Claude Code workflow optimization: queue, remember, codify, verify

An optimized Claude Code workflow runs the working day as small, verified units of work: the message queue steers a running turn without interrupting it, auto memory and CLAUDE.md carry corrections into the next session, a project skill encodes the repeated flow, and each unit ends with an evidence gate instead of a line-by-line read of the diff.

This page is for developers who already use Claude Code daily, and for tech leads who want those habits to be the same across a team. By mid-afternoon you have corrected the same import convention three times, a new session has forgotten the decision you made before lunch, and a diff of 900 lines is waiting for you to read before you dare commit it. The model is not the bottleneck. The loop around it is.

What an optimized Claude Code day gives you

• A way to add instructions while Claude works, without breaking the turn or losing the ability to rewind it.
• A capture habit that sends each correction to the right place: auto memory for you, CLAUDE.md for the team.
• A clean break between tasks with /clear, /compact and /resume, plus a handoff prompt for when you need a fresh context.
• A project skill, /ship-slice, that encodes your “implement, test, review, report” flow in one command.
• An evidence gate that tells you whether a change is ready without reading every line, and who signs it off.
• Recovery steps for the six ways this workflow fails.

Prerequisite: a working install and a first session, covered in the Claude Code development workflow.

Which technique fixes which part of your day?

Symptom	Technique	Deep dive
You wait for a turn to end before adding a detail	Queue messages while Claude works	This page
You re-type the same correction every session	Capture it in auto memory or CLAUDE.md	Claude Code memory
Long sessions drift and repeat old mistakes	Break between units with /clear or /compact	Slash commands by job
You type the same five-step request every day	Codify it as a project skill	Custom commands and skills
You read every diff line before committing	End each unit with an evidence gate	This page, then review by evidence
Two independent tasks fight over the same files	Run them as separate background sessions	Agent view

Steer a running turn with the message queue

To add an instruction while Claude is working, type it and press Enter. Claude Code queues the message instead of interrupting the turn and shows it in gray until Claude starts on it. The timing matters, and the vendor docs state it precisely (Claude Code v2.1.283):

• A queued message reaches Claude as soon as the current tool calls finish, inside the same turn. Messages still queued when the turn ends go out in the order you typed them.
• A queued slash command or ! shell command waits until the turn ends, then runs in the order you queued it. A few commands never queue: /model, /effort and /fast, for example, apply as soon as you send them.
• Ctrl+Enter (or Ctrl+X Ctrl+S in terminals that do not report extended keys) sends the queue now, with your draft behind it; if a queued ! command is first, it interrupts the turn. It needs v2.1.275 or later, so the stable channel (v2.1.274 on 2026-09-26) does not have it yet.
• Up from the first line of the input takes queued entries back into the input box for editing.
• Esc interrupts the turn, keeps the work done so far, and sends what you queued.

Use the queue to steer, not to stack unrelated work. A message that joins a running turn gets no checkpoint, and the /rewind menu does not list it. If that message sends Claude in the wrong direction, you cannot rewind to the moment before it; you can only rewind to your last full prompt. So queue refinements to the current unit (“also cover the empty-string case”), and start the next unit of work as a new prompt after the turn ends.

For a question that should not enter the conversation at all, such as “what was that config file called?”, use /btw. It runs alongside the main turn, sees the conversation so far, has no tools, and adds nothing to the history. To go and find something out, use a subagent instead.

Size the unit of work before you start

A unit of work is the largest change you can verify with one gate: one behaviour, its tests, and nothing else. Four signs that a unit is too big: it crosses a module boundary, it needs two different test commands to verify, you cannot state its acceptance criteria in three bullets, or you would not revert it as a whole. Split it before you prompt, not after the diff arrives.

Commit at the end of every unit. Checkpoints track only edits made through Claude’s file-editing tools; files changed by Bash commands and by subagents (other than a skill forked in the foreground) are not restored by /rewind. Git is the only undo that covers everything.

Copy-paste prompt: start a unit of work with acceptance criteria

Implement one unit of work: rate-limit POST /api/auth/login to 5 attempts
per email per 15 minutes, returning 429 with a Retry-After header.

Acceptance criteria:
1. A 6th attempt within 15 minutes returns 429 and Retry-After in seconds.
2. A successful login resets the counter for that email.
3. Other emails are not affected.

Before writing code, write one failing test per criterion and run it to
show it fails. Then implement until the tests pass. Do not touch files
outside src/auth/ and tests/auth/ without asking. Stop when the criteria
are met; do not refactor neighbouring code.

Keep context across sessions without re-explaining

Two mechanisms carry knowledge into the next session, and they have different owners. When you tell Claude “remember that the API tests need a local Redis”, Claude saves it to auto memory: notes in ~/.claude/projects/<project>/memory/, machine-local, shared by all worktrees of the same repository, and on by default. When you say “add this to CLAUDE.md”, the rule goes into the project file that your whole team loads from git.

The routing rule: a personal preference or a fact about your environment goes to auto memory; a convention every contributor must follow goes to CLAUDE.md, where it is reviewed in a pull request like any other change. Only the first 200 lines or 25 KB of the MEMORY.md index load at session start, and Claude skips anything it can derive from the code, so auto memory is not a place for architecture notes. /memory lists every memory file, opens the one you pick, and toggles auto memory. Claude Code memory covers placement, path-scoped rules and how to prove a rule loads.

Between units, choose deliberately:

Command	What it does	Use it when
/compact [instructions]	Summarizes the conversation so far and keeps going	The next unit continues the same feature
/clear [name]	Starts a new conversation with empty context	The next unit is unrelated; the name labels the old one
/resume [session]	Reopens an earlier conversation by ID or name	You cleared too early or need yesterday’s thread
claude -c	Continues the most recent conversation in this directory	You restarted the terminal and want to pick up where you were

/clear is not destructive: /resume brings the old conversation back, and in the same Claude Code process the rewind menu shows a “previous session” entry at the top. A handoff note is still worth writing when you want a fresh context that carries only the decisions, not the dead ends.

Copy-paste prompt: handoff note before /clear

Write a handoff note for a fresh session, under 200 words, no preamble:
1. The feature and the unit of work we are on.
2. Files changed so far and why, one line each.
3. Decisions made and the alternative we rejected for each.
4. Commands that verify the work, and their last result.
5. The exact next step.
Do not include approaches we abandoned except as rejected alternatives.

Copy-paste prompt: route this session's corrections

List every correction I gave you in this session. For each one, decide:
(a) a team convention every contributor needs: propose the exact line for
    CLAUDE.md and the section it belongs in;
(b) a personal preference or local-environment fact: save it to auto memory;
(c) a one-off: drop it.
Show me the (a) list as a diff to CLAUDE.md and wait for my approval
before editing the file. Do (b) now.

Codify the flow you repeat as a project skill

If you type the same multi-step request more than twice a week, make it a skill. Custom commands have been merged into skills: a file at .claude/commands/ship-slice.md still works, but new work belongs in .claude/skills/<name>/SKILL.md, which adds frontmatter and supporting files. Check it into git so every teammate gets the same /ship-slice.

1. Create the skill directory in the repository root.

   mkdir -p .claude/skills/ship-slice

2. Write .claude/skills/ship-slice/SKILL.md. disable-model-invocation: true means only you can start it, because it edits code and runs your whole gate; $ARGUMENTS receives whatever you type after the command.

   ---
   description: Implement one verified unit of work, test-first, and report evidence.
   argument-hint: "[behaviour to implement]"
   disable-model-invocation: true
   ---
   
   Implement this unit of work: $ARGUMENTS
   
   1. Restate the behaviour as 2-4 numbered acceptance criteria. Stop and
      ask if any criterion is ambiguous.
   2. Write one failing test per criterion. Run it and show the failure.
   3. Implement until the tests pass. Stay inside the module the behaviour
      belongs to; ask before adding a dependency.
   4. Run the full gate: `npm run typecheck`, `npm run lint`, `npm test`.
   5. Report a table: criterion | test name | result. Add the output of
      `git diff --stat` and name any file you were unsure about.
   6. Do not commit. Wait for my approval.

3. Run it in a session.

   /ship-slice reject coupon codes that expired before the order date

4. Adjust the gate commands in step 4 to your repository, then commit the skill so the team reviews it like code.

A tech lead owns this file the way they own the CI configuration: the gate inside it is the team’s definition of “done”. Custom commands and skills covers arguments, invocation control and running a skill in a subagent.

Prove each unit of work without reading every line

Reading a 900-line diff line by line spends the same attention on a renamed variable as on a changed authorization check. The gate below replaces that read with evidence you can check in a few minutes. It is only as strong as the tests, so the acceptance criteria and the failing-first tests carry the weight.

1. Acceptance criteria before code. The criteria in your prompt or skill are the contract. A criterion without a test is unverified.
2. Failing-first tests. Claude shows each new test failing before the fix. A test that never failed may not test anything.
3. Machine gates. Type check, lint and the test suite exit with code 0. Claude reports the commands and their results; you rerun the one you doubt.
4. An independent review pass. Run /code-review on the current diff. It is a bundled skill that reviews the diff for correctness bugs. /code-review --fix applies its findings; when it runs in the background, /rewind does not restore those edits, so commit first.
5. Targeted human reading. You read the evidence table, the git diff --stat, and only the files that touch security, money, data migrations or public interfaces.

Who signs off: the developer merges on this evidence; the tech lead owns the gate definition and audits a sample of merged units against it. Anything that must happen on every change, such as a formatter or a test run before Claude stops, belongs in a hook rather than a prompt, because hooks run regardless of what Claude decides (hooks automation). The wider method is in the test stage of the lifecycle and review by evidence, not diffs.

Copy-paste prompt: evidence report before you commit

Before I commit, produce an evidence report for this unit of work, no prose:
1. Acceptance criteria, each mapped to the test that proves it, with the
   test's result from a fresh run now.
2. The exact commands you ran for typecheck, lint and tests, and their
   exit codes.
3. `git diff --stat`.
4. Every changed file that touches auth, payments, persistence or a public
   API, with one line on what changed in it.
5. Anything you skipped, stubbed or were unsure about.
If any check fails, say so first and stop.

When the Claude Code workflow breaks down

A queued message sent Claude the wrong way, and /rewind does not list it. Messages that join a running turn get no checkpoint. Recovery: press Esc, run /rewind (or Esc twice on an empty input), and restore code and conversation to your last full prompt. This rewinds the whole turn, including the good work Claude did before your message arrived, so commit or copy anything worth keeping first. Next time, send a change of direction as a new prompt after the turn ends.

/rewind restored the conversation but files are still changed. Checkpoints do not track Bash commands, such as npm run codegen or sed, or edits from subagents other than a skill forked in the foreground. Recovery: git status, then git restore the files or git stash the unit. This is why you commit at the end of every unit.

You ran /clear and needed the thread. Recovery: /resume and pick the session, or open the rewind menu in the same process and choose the “previous session” entry. Name conversations with /clear auth-rate-limit so they are easy to find.

Auto memory learned something wrong. Claude keeps applying an outdated fact, such as an old port or a removed script. Recovery: run /memory, open the auto memory folder, and edit or delete the topic file and its line in MEMORY.md. Keep the index short: anything past 200 lines or 25 KB is not loaded at session start; ask Claude to condense MEMORY.md into one line per entry.

Claude starts your skill on its own. A skill without disable-model-invocation: true can be loaded whenever Claude judges it relevant. Recovery: add the field to any skill that commits, deploys or sends messages.

An unattended session did more than you wanted. With v2.1.283 on the latest channel, interactive sessions start in auto mode, where a classifier reviews actions; claude -p still starts in Manual. Recovery: for a headless run, pre-approve exactly what it needs, for example claude -p "run the test suite and fix failures in src/auth" --allowedTools "Edit" "Bash(npm test *)". Use --dangerously-skip-permissions only in a disposable, network-restricted sandbox, never on your working checkout.

How does this workflow look in Codex or Cursor?

The habits carry over, but the commands differ. Codex keeps conventions in AGENTS.md and reviews with /review or codex review; see Codex efficiency hacks. For Cursor, see Cursor time-savers.

Where to go next with your Claude Code workflow

• Efficiency hacks for daily Claude Code work: smaller habits that save minutes without skipping the gate.
• Batch operations: when one change must land across hundreds of files with /batch.
• Agent view: run independent units as parallel background sessions.
• Performance optimization: keep long sessions fast and within budget.