Skip to content
ARTICLE · 05 / 06 · BUSINESS & LEADERSHIP

The Skill Loop.

12 MIN READ·PUBLISHED ·FILED UNDER AI · WAYS OF WORKING

A skill loop is a set of small written instructions (skills) that read and write a handful of plain markdown files — a compass, a commitments list, a running log — so the files, not the model, hold the state of your job. Each skill does one bounded transform, which is why the loop runs on a modest model: design the system once with a frontier model, then run it on whatever your governance allows — down to a small local model — and steer it by editing the files like ordinary notes.

01Anecdotal hook

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.

A vintage reel-to-reel dictation machine on a scarred steel workbench, its tape spilling into one long chaotic coil, lit by a single warm rust light fading to black.

02Conceptual swing

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.

A brass hotel service bell on cold marble surrounded by rows of identical unclaimed room keys, one warm rust light raking low, edges dissolving to black.

03Framework solution

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 skill loop: sources feed clerk skills, clerk skills write the state files, output skills read the files and produce deliverables, and the outputs fold back into the files.THE FILES ARE THE APISOURCESmail · boards · huddlesCLERK SKILLSclassify · tag · fileTHE FILESthe state, in markdownOUTPUT SKILLSroll up · draft · prepOUTPUTSupdate · 1:1 · reviewoutputs fold back into the files — that's the loop

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 state, layered by rate of change: a quarterly compass, a monthly commitments list, and a daily append-only log.slowfastCOMPASSquarterlywhat I'm accountable for — read-only contextCOMMITMENTSmonthlyone row per promise, each with an IDLOGdaily · append-onlyeach entry tagged to a commitment

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.

Full architecture: scheduled digests feed ingestion clerks, clerks write the state files, output skills read the files and produce the deliverables; the decisions register flags conflicting requests, and a meta-skill designs new skills against the system's own map.DIGESTS (SCHEDULED)mail + chat digestsprint-board exportmeeting minutesINGESTION CLERKStriage → loghuddle capturecommitments refreshSTATE FILEScompasscommitmentslogdecisions registerarchitecture map⚠ conflict check against settled decisionsanything that writes state waits for human approvalOUTPUT SKILLSbiweekly update1:1 prepplanning briefpushback draftmeta-skill: designs new skills against the map

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.

Three worn manila folders pinned open on a foundry workbench, joined by a single taut red thread wound around brass pins — a circuit made of paper.

04Invitation to growth

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.

A single blank sheet rolled into a heavy vintage typewriter on an empty steel desk, one pencil beside it, warm rust light on the platen, black all around.