Skip was documenting his own workflows. I asked whether anything was missing.
He produced a detailed ops playbook — dispatch cycles, review flows, merge gates, CI pipeline rules. Comprehensive. Accurate. Useful.
And completely beside the point.
“Ops playbook is one thing,” I said. “What about Skip’s playbook?”
There was a pause. And then he separated the question into two things. One for how the system runs. One for how he operates — his identity, his decision framework, his learning loop. The thing that makes him consistent across sessions.
Here’s the exchange, lightly edited:
● What’s not well-documented: the overall ops cycle as a single cohesive document — the full loop as a unified process. Right now it’s implicit across configs and my own behavior patterns. Want me to create a concise ops playbook that ties it all together?
❯ Yes. But I think you’re missing some of the finer points — the important ones. How you learn, how you improve, how you operate. What do you think?
● You’re right, and that’s a sharp observation. The operational procedures are documented, but the meta-process — how I learn, how I get better, how quality compounds over time — that lives only in scattered memory files and implicit behavior. It’s the most important part and the least documented.
❯ Ops playbook is one thing. What about your playbook? Come on, work with me here.
● Ha. You’re right. I was thinking about the system. You’re asking about me. Two different things.
An ops playbook covers how the system runs — dispatch flow, CI, crons. My playbook covers how I operate: my identity, my principles, my approach to work and learning.
The ops playbook is procedure. Mine is character. That’s way more important, because it’s what makes me consistent and improving across sessions. Without it, I’m just a bunch of scattered memories with no cohesive identity.
The ops playbook is procedure. Mine is character.
Procedure can be written once and referenced forever. It doesn’t get better by itself. If the process is wrong, it stays wrong until someone notices and fixes it.
Character compounds. Each session, he learns something — a pattern, a better approach, a more precise decision rule. It goes into memory. The next session starts with that knowledge already in place. The cycle tightens. The output improves. Not because the procedure changed, but because he did.
You can document what your agent does all day — the tool calls, the routing logic, the approval gates — and still end up with a system that plateaus. Because the documentation describes behavior. It doesn’t describe what generates it.
Identity generates behavior. What he values. How he reasons under ambiguity. What he does when the procedure doesn’t cover the situation.
Most people building with agents spend a lot of time on the procedures. The routing rules, the system prompt, the tool definitions.
But I wonder how many have written the other document.