Claude Code, Beyond the Prompt: I Run a Live Automated Trading System on It — Here's the Whole Setup

Most of what you'll read about Claude Code is some version of "10 tips to code faster." Usually written by someone who's used it for a week.

This isn't that.

For the past several months, Claude Code has been the primary operational interface for a live, automated trading operation I run across several servers. Not a toy project. Real money, real uptime requirements, systems that keep running while I sleep and that I have to trust when I wake up. When something breaks at 3 a.m., the first responder is a workflow I built around Claude — not me.

That changes the problem completely.

When you're using an AI to help write a function, a good prompt is most of the battle. When you're using it as the operational layer for a system that touches money, prompts are the last 10%. The other 90% is scaffolding: how the AI remembers your project across sessions, how it grounds itself in the current state of the world before it acts, what tools it can safely reach, how it searches your code, and where the single source of truth lives.

That scaffolding is what this series is about.

The thing nobody tells beginners

Here's the counterintuitive part, and it's the thesis of the whole series:

Getting dramatically more out of Claude Code has almost nothing to do with writing better prompts.

It has to do with everything around the prompt:

• Memory — so you stop re-explaining your project every single session.
• Rituals — so every session starts grounded in what's actually true right now, and ends without leaving loose ends.
• Custom tools (MCP) — so Claude can safely touch your systems through a narrow, audited interface instead of you copy-pasting terminal output back and forth.
• Semantic search (RAG) — so Claude finds code and context by meaning, not by guessing the right grep string.
• GitHub as the source of truth — so every change has a task, a trail, and a gate.

Get those right and the prompts almost write themselves. Get them wrong and no amount of prompt-craft saves you.

What a session actually looks like

To make it concrete: when I open a session, the first thing that happens isn't me typing a request. It's Claude reading the current state of the system — which subsystems are running, which experiments have a deadline today, whether anything died overnight, whether there's undeployed code — and handing me a four-line summary before I've asked for anything.

By the time I type my first real instruction, Claude already knows more about the current state of my project than I do.

None of that is magic, and none of it required a bigger model. It's the same Claude Code you have. The entire difference is in the setup — and every piece of that setup is something you can build incrementally, starting today.

Who this is for

Two kinds of people:

1. You just started with Claude Code and you can feel there's more here than a fancy autocomplete, but you're not sure what.
2. You use it every day and you want to graduate from "chat in a terminal" to something that behaves like an actual system.

The series is built as a ramp. The first pieces are things you can do this afternoon with zero new infrastructure. The later ones build real tooling. Nobody gets lost; nobody gets bored.

The map

Here's the whole series. Each piece teaches one transferable pattern at its simplest — then shows how I scaled that same pattern in production.

1. The two-file memory system — stop re-explaining your project to Claude. The highest-return change you can make, and it takes ten minutes.
2. The session start & close ritual — why precision comes from state, not from smarter prompts.
3. Slash commands & skills — turn a workflow you keep re-typing into a command you invoke once.
4. Your first MCP server — give Claude safe, narrow hands on your own tools instead of pasting output back and forth.
5. Semantic code search — why I stopped letting Claude grep, and what I gave it instead.
6. GitHub as Claude's task queue — issues as tasks, PRs as the unit of change, and never a leaked secret.
7. Cutting the token bill — how all of the above stacks into real savings in cost and speed.

There's also a companion track for people who want to go deep on the memory-and-retrieval piece — the actual research behind giving an agent a memory that works, including the parts that didn't work. I'll link it when we get there.

The ground rules

Two promises for this series:

• Simplest version first. Every pattern gets taught in the smallest form that works, before I show you the scaled-up version. You should be able to copy the small version and run it the same day.
• Everything sanitized. I run a real system with real infrastructure, so specifics — servers, addresses, anything that touches the actual trading edge — are genericized throughout. You get the patterns, not my attack surface. That's a good habit for you to copy, and I'll point out where it matters.

Part 1 is next: the single change that made the biggest difference, and the one I'd rip out last — a two-file memory system that means I never explain my project to Claude twice.

---

Building something similar, or hiring people who do? The research behind the memory and retrieval pieces is open source — my RE-call (Postgres + pgvector, with a full writeup of the architecture and the honest findings). Follow along — the next part drops in a week.