About a year ago I started working on a second-order harness for myself where my only intention was to try to not be too fancy about the approach. I wanted to share that project because it turned out to work exceptionally well for me and may for others.
But ultimately that ‘exceptional’ output is an output that is made for me, that enriches in some way my own agency and creativity. It has more to do with how I went about creating it, not what’s actually in it. Which I want to write about first.
I was doing the wrong job
AI moves unusually quickly. Every week brings new models, techniques, workflows, benchmarks and opinions about how you're supposed to work. It creates the feeling that if you stop paying attention you'll be left behind and makes it tempting to constantly optimize your setup instead of your work.
This feeling of falling behind treats all AI knowledge as one 'job', but it's at the very least two:
- The model's job is to know about the model.
- Your job is to know about the work.
These have wildly different half-lives.
The feed of content we're all buried in (model updates, new tools, frameworks, social content, articles, which I'll refer to as just the feed hereon for simplicity's sake), almost exclusively helps with the first job. That feed is the fastest-depreciating asset there is because the model is trained on it.
The people discovering better ways to work with it matter enormously. But once those ideas become public and general, they don't stay ours for very long. In most kinds of work it's enough to be right. In this kind, being right has a shelf life of about one release. The hours I spent keeping up were hours spent hoarding the single most rapidly-depreciating thing in the room.
Major capability shifts are worth paying attention to because they expand what's possible. But most incremental updates don't require me to rethink how I work. This is why in this harness I run a state-bump on each new Claude Code release so I know the agent has access to the information it needs to do its job.
So with this idea I started using this one project folder to yarn with Claude whenever I wanted to refine how we worked together. I never asked it to create anything.
I'd start talking about a problem or an idea with the words I had about them before looking online about it. I asked a lot of questions and spent most of the time challenging whatever either of us assumed straight away, because almost every time an assumption broke there was a better idea sitting behind it. Sometimes this produced a primitive and sometimes it didn't. Most of them were eventually deleted.
The model can't have what I want
The model gets better every few months without any help from me, but what I want, it can only get from me.
This is easier to say when you already have judgment to fall back on. But I don't think the beginner's version is 'keep up more'. The feed feels like learning and is mostly spectating; judgment comes from thinking for yourself and doing work and being wrong about it often. So the advice holds for them too, it's just less comforting.
I forgot that I am a person with ideas and expertise and a new tool to help me do the things that excite me better and faster.
Really no matter the job you do, your competitive advantage probably isn't knowing that Claude Fable 5 improved tool use by 8%. It's understanding your domain deeply enough to recognize a good answer when you see one.
The bottleneck in most cases (for the people like me and who resonate with this problem) is not the model, and not your lack of knowledge about it.
As I worked on this harness I've gradually tried to distill these ideas into it. It became a funnel I've called agent-kitchen that takes a person's raw thoughts, ideas, and earned expertise, and produces something that helps an agent do better at what matters to that person.
The Harness
Agent-kitchen is a second-order harness: it is a kitchen for the things that configure coding agents (skills, hooks, rules, CLAUDE.md, workflows). It runs as dotfiles for the agent in the form of two plugins under a marketplace:
- Cook makes the tools, tastes them, dates them, throws out what's gone stale.
- Serve is what's survived for me so far. It still tastes better than store-bought.
The kitchen is built on the idea that:
A frontier model in 2026 is very competent at most things, but its default in any domain is the competent average version of the thing. The artifacts here are commitments that drag the model off that median in a chosen direction.
Every artifact competes with two forces: the unaided frontier model, which absorbs generic craft with each release, and the owner's time, which every artifact charges rent on.
So durable value comes from what the model cannot have: the owner's taste and intent made operational, local truths of a repo or team, verified facts from after the training cutoff, and failures actually observed in sessions.
Everything else gets absorbed, so deletion is the expected end of every artifact here, not a failure of one.
I should mention this is something I actively maintain and rework regularly. There are tests for the model to run and tests that I run, which is mostly just me asking Claude to use a skill, review what it produced, and then I poke and prod at it until it achieves what I expected or wanted.
I'll use other skills that are similar and get it to use each for the same task (a task I actually need to do and have a very clear idea about what an 'excellent' output is). I compare them and work backwards through what Claude did in each.
Cook
Cook is where artifacts come from, it can run as a loop or as-needed.
| Skill | Purpose |
|---|---|
| forge | Routes a behavior through a triage ladder to the right surface (skill, hook, path-scoped rule, CLAUDE.md, workflow, subagent, MCP). Applies a consistent stance that judges each artifact by the work it causes the agent to produce, not by the artifact itself. |
| harness-audit | Inventories everything loaded at session start, measures per-session token cost, and runs four checks: self-consistency, duplication across scopes, enforcement parity, and scope discipline. Built to remove artifacts rather than add them. |
| harvest | Mines session transcripts for corrections the user had to make more than once, deduplicates them against the existing harness, and forwards surviving candidates to Forge as earned-intent evidence. The "without-the-skill" baseline has already been observed in production during those sessions. |
| ingest | Converts user-provided resources into an artifact by spawning one reader subagent per source, grounding the result in verbatim quotes. |
As a loop:
Serve
Everything in Serve should earn its place only by beating the unaided current model on the gap that created it, checked by a runnable probe and not assumed (process skills are exempt: their value is the owner wanting the procedure, which no release absorbs).
Each such skill keeps the gap that earned it as a runnable fixture in evals/probes.md: the verbatim prompt, what the bare model gets wrong and the pass criterion.
On each model release the probes replay against the bare model in a near-clean session (safe-mode still leaks some account context). Verdicts land in a per-model table and CHANGELOG.md. When every probe passes unaided, the model has absorbed the skill's job and the skill is deleted.
Absorption is not monotonic: a case one model absorbed can regress on the next model line, so probes never retire while the skill lives.
STATE.md + HACKS.md
Verified snapshot of Claude Code's surfaces and lesser-known features, re-checked against the live changelog on each release.
CHANGELOG.md
The provenance ledger: why each artifact exists, what it was re-tested against, and the keep/revise/delete verdicts. The artifacts themselves carry only a one-line model pin.
Top comments (0)