The Skill Loop.

A few weeks ago I dictated my entire job into a chat window. Not a tidy summary — the real thing, ums included.

The escalations that arrive by mail, phone and chat. The development plan that's supposed to work as a compass. The expectations document that gets retuned every quarter. The team OKRs. The twelve-week sprint rhythm. The international forums that hand priorities down and expect input back. The weekly commercial review. The two daily huddles nobody records. A six-minute ramble covering everything that steers — or shoves — my agenda.

Three hours later I had something I'd never managed to build in years of tidy planning documents: a system that actually holds all of it at once. Not an app. Eighteen small written instructions and a handful of markdown files.

Most leaders I know have quietly built themselves an AI chief of staff: open the chat window, paste in the calendar and the worries, get a plan. It genuinely helps. But look at what it actually is.

It forgets — every session starts from zero, so you spend ten minutes re-explaining your own life to it. It's rented — your priorities and your Tuesday-at-4pm worries travel to someone else's cloud, on subscription. And it's heavy — you're spinning up a model that can pass the bar exam to decide whether the budget review outranks the one-on-one.

That's not a capability problem; it's an architecture problem. The state of your job — what you're accountable for, what you've committed to, what happened yesterday — lives scattered across systems, and the chat window re-derives it from scratch every morning. The thing that should compound is the thing that evaporates at midnight.

The fix sounds almost too unglamorous to be interesting: put the state in files, and let small instructions move it around. The design principle that makes it work — the one sentence I'd keep if I could keep only one — is this: the files are the API. Skills never talk to each other. They read from and write to a small set of plain documents with fixed shapes. That's what makes the system composable, checkable, and — this matters later — portable.

The files, layered by how fast they change. A compass (slow, quarterly): what I'm accountable for and how I want to operate — the development plan and the role expectations, distilled. A commitments list (monthly): every OKR, sprint priority and standing promise, one row each, with an ID. And a running log (daily, append-only): everything that happened — escalation, stuck sprint item, huddle outcome — each entry tagged with the commitment it touches. That tag is the glue: a modest model rolls up tagged rows flawlessly; it's inferring untagged relationships across free text where it stumbles.

The skills, each one a clerk, not a thinker. One reads the day's digest of mail and chat and files entries into the log. One captures the unrecorded huddles — I dictate three bullets, it formats them into the same schema. One drafts the biweekly update to my manager by rolling the log up against the commitments. One preps every one-on-one from the log filtered by person. Each skill does exactly one transform — never extract and synthesize — and anything that touches the state files waits for my approval. The prompts say it in so many words: you are a clerk; you do not interpret.

Two parts earn their keep beyond time-saving. A decisions register: every settled agreement as a row, including — crucially — what was ruled out, in the language requests actually arrive in. Incoming asks that break an agreement get flagged automatically, and the drafting skill writes the polite, firm pushback citing the forum, the date, and the legitimate path to revisit. Held lines stop being invisible non-events and show up as delivered work. And a meta-skill that designs any future skill against a maintained map of the system, reusing what exists before inventing anything new — the system grows without rotting.

Now the part that should interest anyone who owns a P&L or a governance checklist. Because the state is plain text and every skill is a bounded, clerk-sized job, the model can be modest. I designed this in one morning with a frontier model — Claude, in this case, which kept arguing me out of documents I didn't need and wrote all eighteen skill prompts — and it runs on a much lighter setup: each prompt pasted into a skill builder on an agentic Gemini runtime, pointed at ordinary workspace docs. The expensive intelligence is spent once, at design time; the daily work is classify, tag, format, roll up. Any executive recognizes the shape: consultants design the process, your own team runs it. And the same property is what makes the pattern portable — the loop doesn't care what executes it. Build it with the frontier model; run it on the approved corporate stack, or, for the version that holds your personal notes, on a small model on a machine you own. The files never have to leave the building.

Honest limits, so this doesn't read like a brochure. The loop doesn't make judgment calls — it surfaces them; the Tuesday-at-4pm conversation with a skeptical CFO is still mine. A register polluted with things that were merely discussed, rather than agreed, destroys its own authority the first time someone challenges it — so anything ambiguous goes to a “was this actually agreed?” list instead of into the record. And the files drift if you never read them. You do read them, though. They're your week.

If you want to see the pattern at production scale rather than personal scale: this website runs on it. Skills read a content registry and write review queues; a weekly scan reads five sources and writes one issue; a memory file briefs every session. Same loop, bigger files.

You don't need eighteen skills on day one. You need one file called log.md, one written instruction — “file today's mess into this schema, tag each entry with the commitment it touches” — and whatever model you already use. If it earns its place, add the roll-up skill. Then the compass. Steering never gets more complicated than editing your own notes: when the system prioritizes the wrong things, you don't engineer prompts, you correct a file with a pencil.

The whole thing cost me a morning to design and minutes a day to run, and everything it learns stays in files I can read end-to-end. If you build one, I'd genuinely like to hear what your files ended up being called — mine keep renaming themselves.

How this landed inside a real team — the change-management half — is in The Colander.