The AI Harness Designer

The work itself. Not what you do, but a specific task from this week you would rather not have done yourself. It pushes back if you answer with a category.

How often it comes up. This single answer decides more than any other.

Which tools that work touches. The apps you actually open, not the integrations you imagine.

How comfortable you are in a terminal. Answered honestly, this changes what gets recommended rather than just how it gets explained.

How much autonomy you want. Including the question most people skip, which is what it must never do without asking.

What is annoying about your setup now. Symptoms map cleanly onto missing components, and this question often makes the whole answer obvious.

---

The part most coverage skips: the skip list is mandatory

Every guide to this tells you what to add. The value is in what to leave out, and the skill treats that as a requirement rather than a nicety. If every component gets recommended, the interview was not used.

Two rules govern that section.

Reasons must be specific to you. "Subagents help with context management" is a fact about subagents. "Skip subagents, because your work is single file edits that finish in one pass and the isolation would cost more setup than it saves" is advice. Only the second one is worth writing down.

The first build caps at three components. Three that get used daily beat eight that half work. Everything else goes on a later list with a named trigger, meaning a specific observable event rather than a vague "when you are ready."

The outcome the skill is built for is somebody arriving planning to install six things and leaving having installed one.

---

Frequency is the gate

Worth understanding because it is the rule doing most of the work behind the recommendations.

Daily or weekly work justifies setup. Monthly work usually does not. A component that saves ten minutes on a task performed twice a year is a net loss once you count installing it, configuring it, and remembering it exists.

This is also the honest test for any tool anybody recommends to you. Not whether it would help, but how often the thing it helps with actually happens.

---

The blueprint

Four parts, in this order.

Build now. One to three components. Each explains why you specifically need it, quoting your own answers back, what it does in plain terms, the exact command, and an honest time estimate.

Add later. Things that would help but do not clear the bar yet, each with the trigger that would change that.

Skip entirely. Section four.

The order to do it in. Numbered, with a first step you can finish in ten minutes so you have something working early.

It reflects your answers back before any of that, so you can correct a misunderstanding before installing something on the strength of it.

---

If your setup is already bloated

Say so and it inverts the process. Audit first, add nothing.

It asks what you have installed and when you last used each thing. Anything you cannot remember using in the last month is a candidate for removal, and removing it usually improves the setup more than anything you could add, because it frees context and reduces the number of similar tools the model chooses between. Then it runs the normal interview for whatever is genuinely missing.

---

The three artifacts you need

One, the completed blueprint. Save it. It is the record of why your setup looks the way it does, which matters in three months when you are tempted to add something.

Two, a working first component. One thing installed and used daily beats a perfect plan. Build the first item and use it for a week before touching the rest.

Three, a written install log, 200 to 400 words and growing, and almost nobody has one. One file recording what you installed, the date, and one line on why. Add a line each time you install or remove something. The reason this matters more than it sounds is that setups rot invisibly. In six months you will have components you cannot remember adding and cannot justify keeping, and without the log there is no way to tell the difference between something load bearing and something you tried once. This is also what makes the audit in section seven produce a real answer rather than a guess.

---

If something goes wrong

Honest limits

It does not know your business, only what you tell it in the interview. Answer the work question with "marketing" and you get a generic blueprint, which is a fair reflection of a generic answer.

It recommends components, not outcomes. A perfect harness around a badly defined job still produces a badly defined job faster.

The skip list is opinionated by design and it will occasionally talk you out of something you actually wanted. Push back if so, since the reasoning is visible and arguable rather than hidden.

And it will not build anything until you approve the blueprint. When it does build, it does one component at a time and confirms each works before starting the next, because three half configured components are worse than one working one. A broken hook or a misconfigured server fails silently, and you spend weeks assuming it is fine.

---

What this changes

The instinct with a new tool is to collect. Install what people recommend, keep it in case it is useful, add more when something feels missing.

That instinct is wrong here, and it is wrong in a way that is invisible, because the cost shows up as the model getting quietly worse rather than as anything breaking. What changes once you have run this is that adding a component starts to feel like a decision with a price attached, which is what it always was.

---

Download

LINK