Part 2 of Claude Code, Beyond the Prompt — patterns from running a live automated trading system on Claude Code. Part 1: the two-file memory system.
In Part 1 you gave Claude a memory file. Good. But if you've used it for a few days, you've probably noticed something uncomfortable: Claude can still be confidently wrong.
It edits a file that was mid-refactor. It "fixes" a bug that's already fixed on another branch. It assumes you're on main when you're three commits into a feature branch. It does great work and then forgets to write down what it changed, so tomorrow's memory file is already a lie.
That's not a memory problem. Part 1 solved storage. This is a ritual problem — and it's the difference between an AI that's occasionally brilliant and one you can actually trust to touch things.
Precision comes from state, not from prompts
Here's the reframe. Almost every "why did Claude do that?" moment is really a state-ignorance moment. It acted on an assumption about the current situation that happened to be wrong. Not because the prompt was bad — because it didn't check reality first.
Think about how a good engineer starts work. They don't dive straight into typing. They orient: What branch am I on? What's deployed? What's broken right now? What did I leave half-finished yesterday? Thirty seconds of grounding, then they work. And when they stop, they write down what changed so the next person — including future them — isn't flying blind.
Claude will do exactly this. It just won't do it on its own. You have to make it a ritual: a fixed checklist that runs at the start and close of every session, whether or not you remember to ask.
Two halves. Start grounds Claude in what's true before it acts. Close writes what changed back into truth before it leaves. Together they make a loop where state never silently drifts.
Session start: ground before you act
The simplest version you can adopt today — put this in your CLAUDE.md:
## Session start (run before the first task)
1. Read MEMORY.md → the "Now" section.
2. Run `git status` and `git log --oneline -5`.
3. Report a 3-line summary: current branch, uncommitted changes, what's in flight.
That's the whole start ritual. Now Claude's first action of the session is informed. Before you've even typed your real request, it has told you what branch you're on and what's uncommitted — and half the time that summary alone catches something: "oh right, I never committed yesterday's change," or "wait, I'm still on the experiment branch."
Why this works: a fixed checklist catches the failures you'd never think to check for. You don't ask "did I leave uncommitted work?" precisely because you've forgotten that you did. The ritual catches the unknowns. That's the entire value — it's not about the individual checks, it's about running them unconditionally.
How I scaled it: a spine and a lazy layer
Running a system where some subsystems touch real money, my session start splits into two tiers — and the split is the whole design:
A mandatory safety spine that ALWAYS runs, even for a trivial one-line question. These are the cheap, high-stakes checks: read current state, confirm the live money-touching systems are actually alive, check whether anything died overnight, check for a deploy that's pending or a deadline that lands today. It costs a few seconds. It has saved me from acting while a subsystem was silently down more than once.
Task-conditional enrichment that only runs when the task needs it. Deep database health, long history, heavy diagnostics — there's no reason a "fix this typo" turn should pay for any of that. It loads lazily, only when I'm actually doing DB or ops work.
The output is always the same shape: a four-line TL;DR — branch, deploy status, system health, anything anomalous — that I read before I type my real instruction.
The principle transfers to any project, money or not: separate "always, cheap, safety-critical" from "sometimes, expensive, task-specific." Never make a quick session pay for the heavy checks. Never let any session skip the cheap ones.
Session close: loop before you leave
The mirror image. Before ending a session that changed anything:
## Session close (run before ending a session that changed anything)
1. `git status` — anything uncommitted? Commit it or flag it explicitly.
2. If code needs deploying, deploy it now — don't leave a half-done handoff.
3. Update MEMORY.md: what changed, what's next.
4. Give a 2-line summary: what changed, what's still pending.
Step 3 is what keeps Part 1's memory file from rotting. Remember the promise from last time — a memory file is only as good as the habit that keeps it current. This is the habit. You don't rely on willpower; you make "update MEMORY.md" step 3 of a checklist that runs every time.
The half-done handoff is the thing that bites you
The single most valuable lesson in this whole article: the thing that leaves you exposed is the half-finished handoff.
"I'll deploy that later." "I'll write it down next time." Later never comes. And now your memory file says one thing, your repository says another, and production says a third. Every one of my worst state-drift incidents started with a change that was almost done at the end of a session.
So the close ritual has a hard rule: if a change is meant to ship, it ships in the session — committed, pushed, deployed, verified — or it gets flagged loudly as incomplete. No silent "I'll finish this tomorrow." Close the loop while you still have the context loaded.
Why a ritual beats "just ask when it matters"
The obvious objection: why not just ask Claude to check things when it's relevant?
Because relevance is exactly what you can't see. The checks that matter most are the ones for problems you don't know you have. A ritual is unconditional on purpose — it spends thirty predictable seconds to eliminate an unpredictable class of mistakes. That trade is almost always worth it.
Making it automatic
Two levels:
-
The lightweight way (start here): the checklists above, dropped into
CLAUDE.md. Claude follows written instructions. This alone gets you 90% of the value with zero infrastructure. -
The heavier way: Claude Code supports hooks — commands that fire automatically on events like session start and session end. I use a session-end hook to keep my memory index fresh without thinking about it. Hooks are a rabbit hole, and you don't need them yet; the
CLAUDE.mdversion is the right beginner path. Just know the ceiling is higher when you want it.
The honest payoff
Again — no miracle claims. Concretely: far fewer "why did it do that?" moments, because the class of state-ignorance mistakes mostly disappears. Your memory file stays true without you policing it, because updating it is step 3 of a routine instead of an act of discipline. And you personally start every session already oriented, which — on a bad day, on a complex project — is worth more than any single feature.
The prompt was never the bottleneck. Grounding was.
Next
By now you've written the same start-and-close instructions, the same review checklist, the same "run the tests and summarize" a dozen times. Part 3 is where you stop repeating yourself: packaging a workflow into a slash command (and its bigger sibling, a skill) so you invoke it by name instead of re-typing it every session.
Part 2 of a series on running real systems on Claude Code. The deeper agent-memory research is open source — see RE-call. Part 3 next week.
Top comments (0)