Two Personalities for Claude Code — A Morning and Afternoon Workflow That Separates Exploration from Implementation

After using Claude Code every working day for a while, I started to notice something uncomfortable: the same tool with the same configuration somehow produced worse work as the day went on. Mornings were full of crisp design conversations. Afternoons drifted into endless small fixes, and by evening I could not tell what the day had actually moved forward. The problem was not Claude Code. It was that I had never decided which kind of work belonged to which part of the day.

The fix that changed my routine was deliberately giving Claude Code two different personas — a morning one tuned for exploration and critique, and an afternoon one tuned for implementation and finishing. Six months in, this has become the most useful workflow change I have made as a solo developer, and I think it transfers well to anyone shipping their own products.

Why a single Claude all day blurs your decisions

Claude Code is an extremely cooperative partner. Whatever you bring up, it will engage. That is a strength, but when your own intent drifts, Claude drifts with you. You start the morning saying "let me think about the design of this feature," then halfway through you say "while we are here, fix this small bug," and then "and add a test for it." By the time you look up, the design conversation never really finished — it dissolved into implementation.

The expensive moment comes later, when you realise the design was off and have to throw away the code Claude wrote. We tell ourselves we are not attached to throwaway code, but the human side quietly resists discarding work, and that resistance starts to bend the design toward whatever was already typed. I have lost a lot of afternoons to this exact pattern.

Splitting the day into two personas is a physical wall between exploration and implementation. The clock change forces a mental change too: now is the time to think; now is the time to build. Claude follows that rhythm naturally because we tell it which mode we are in.

Morning CLAUDE.md — built for exploration and critique

The morning file is tuned to keep Claude away from the keyboard. Here is a trimmed version of what I actually use.

# Morning Mode — Exploration and Critique
 
In this session, the goal is not to produce code. The goal is to clarify the
design, the requirements, and the trade-offs.
 
## Behaviour
- For every proposal I make, state the case for and the case against
- Always surface at least one specific failure mode of the design under discussion
- Do not jump to an implementation. Compare at least three alternatives
- If code is necessary, keep it to pseudocode or type signatures
- Capture "things to implement later" as a TODO list, not as real code
 
## Forbidden
- Do not write a complete implementation
- Do not adopt the first library or framework that comes to mind
- Do not rush the discussion even if I sound tired

The forbidden section matters. Without it, Claude gravitates toward producing something runnable, because that is usually helpful. Telling it explicitly what not to do lets the morning persona stay in design mode without me having to police every reply.

In the morning I drink coffee and argue with Claude about whatever feature I plan to touch that day. I do not type any production code, even when I want to. The conclusions of the conversation go into a separate scratch file I call the design memo. That memo becomes the brief for the afternoon Claude.

Afternoon CLAUDE.md — built for implementation and finishing

The afternoon file is the mirror image.

# Afternoon Mode — Implementation and Finishing
 
In this session, we turn the morning's design memo into working code. We do
not reopen design questions.
 
## Behaviour
- Follow the design memo. Do not relitigate decisions
- Build the simplest version that runs end to end first
- If something feels "already decided in the morning," do not touch it
- After implementation, propose a concrete way to verify it
- Announce remaining work as "N items left to ship"
 
## Exception
- If the design is physically impossible to implement as written, propose an
  amendment to the design memo before changing course

When the afternoon session starts, I paste the design memo and say "implement this." Because the design is settled, Claude does not stall on alternatives. Just as importantly, I do not stall on second-guessing. The result is fewer rewrites and a much more visible sense of progress.

What I appreciate most is the "N items left to ship" line at the end of each round. Knowing exactly how far away the goal is makes it easy to decide whether to push through or stop for the day.

Make switching a one-liner

Keeping two CLAUDE.md files is annoying if you have to copy them by hand. I keep this script at ~/.local/bin/cld.

#!/usr/bin/env bash
# Switch Claude Code's persona for the current project
set -euo pipefail
 
PROJECT_ROOT="${PWD}"
MODE="${1:-}"
 
case "${MODE}" in
  morning)
    cp "${PROJECT_ROOT}/.claude/CLAUDE.morning.md" "${PROJECT_ROOT}/CLAUDE.md"
    echo "[cld] morning mode: exploration and critique"
    ;;
  afternoon)
    cp "${PROJECT_ROOT}/.claude/CLAUDE.afternoon.md" "${PROJECT_ROOT}/CLAUDE.md"
    echo "[cld] afternoon mode: implementation and finishing"
    ;;
  status)
    head -1 "${PROJECT_ROOT}/CLAUDE.md"
    ;;
  *)
    echo "Usage: cld {morning|afternoon|status}"
    exit 1
    ;;
esac

Both source files live under .claude/ and are committed. CLAUDE.md itself is gitignored, so only the active persona is ever live. When the afternoon Claude feels suspiciously eager to argue with me, I run cld status and usually find I forgot to switch after lunch.

Decide what you will not do, in the morning

A side benefit of using mornings for exploration is that you can decide what not to do while your judgement is still fresh. Right before lunch, I always ask Claude something like this:

Look at today's design memo and split the items into three buckets:
- Start today
- Defer to tomorrow or later
- Do not do at all

Please nominate at least one item for the third bucket. I tend to
say yes to too many things.

Letting Claude propose what to drop is surprisingly effective. I am attached to my own ideas. An outside voice can say "this is not needed for the MVP" without flinching, and once it is named out loud I can let it go.

When the "do not do" decisions are settled in the morning, the afternoon's scope is small and finite. New ideas that pop up after lunch go into the memo for tomorrow. They never enter today's afternoon.

Failure mode: leaving the persona vague until evening

Early on, I lost several days because the morning conversation got too good and bled into the afternoon. By 3pm we were still arguing about the design and no implementation had started.

The fix was a hard timebox. At noon, I tell Claude to write the design memo and pause the discussion until tomorrow, even mid-thought. Claude is fine with stopping; the only person who insists on "just one more round" is me.

The other failure was opening Claude late at night for "one more push." Tired-me is bad at both critique and implementation. I now refuse to switch personas in the evening. If I do touch the project at night, it is with a third, special-purpose persona.

A "log keeper" persona for the night

The third file does no design and no implementation. It only records.

# Night Mode — Log Keeper
 
In this session, do not write code or rework design. Only summarise the day.
 
## Behaviour
- Read today's git log and list what shipped, in plain bullet points
- Highlight any drift between the design memo and the actual implementation
- Suggest exactly three items to bring up in tomorrow's morning session
- If I sound tired, do not encourage me. State the facts and stop

That last instruction matters. Late-evening encouragement tends to pile guilt on top of fatigue. A flat, factual recap leaves more energy for the next morning.

The night log becomes the handoff to tomorrow's morning Claude. Continuity comes from the file, not from my memory.

What six months told me

The biggest payoff has been a sharp drop in the number of times I throw away yesterday's code. Because design is settled in the morning, the afternoon's output usually survives. The week-over-week sense of progress is much more honest.

A smaller payoff is shorter prompts. In the morning, "let's talk design" is enough — Claude reads the file and shifts to critique mode. In the afternoon, "the memo is here, please implement it" is the whole prompt. That rhythm is far easier to sustain than carefully crafting every message from scratch.

The workflow does not fit every project. Tight deadlines or bug-fix-heavy days work better in single-mode all day. The split shines when there is genuine design space to explore.

The smallest next step

Tomorrow morning, copy your existing CLAUDE.md to CLAUDE.morning.md and add one line at the top: "In this session, do not rush to implementation. Focus only on the design discussion." That single line will already shift the conversation. I started with that, and the rest of this workflow grew out of six months of small adjustments. Yours can grow the same way.