The AI Harness Designer
A skill that decides what to install, and what to leave out.
A harness is the layer around the model, meaning persistent project context, tools, reusable skills and operating rules. Most setups fail by having too much rather than too little, because every connected server loads its tool definitions into context before you type a word and overlapping tool names measurably degrade selection. This skill interviews you across seven questions, then produces a blueprint in four parts: build now, add later, skip entirely, and the order to do it in. It runs in Claude Code, Codex and the Claude apps. I built it for my own setup after installing far too much.
Why does adding tools to Claude eventually make it worse?
Because everything you install costs context before you type anything. Tool definitions from every connected server, every skill description, the instruction file, the permission rules. All of it sits in the window ahead of your actual work.
The effects compound in the wrong direction. Context holding tool descriptions cannot hold your work. Tools with similar names make selection harder, so the model picks wrong more often. And components installed but never used still cost, because the cost lands when they load rather than when they run.
So the common failure is not an empty setup. It is six servers connected for tools touched twice a year, subagents built as specialists that never get invoked, and an instruction file grown into a wall of text nobody reads, including the model.
The barrier that used to exist was that nobody could tell you which components you specifically needed. The advice was generic because the advisor did not know your work. That is what this fixes: it asks first.
Install it
Claude desktop or web app. Turn on code execution before anything else, under Settings and then Capabilities. Skip that and the Skills menu is greyed out, which is the most common reason people conclude their plan is wrong when it is not. On Team and Enterprise an owner controls this setting. Then open Settings, find Skills under either Capabilities or Customize depending on your version, click the plus, and upload the ZIP.
Claude Code.
mkdir -p ~/.claude/skills
unzip ai-harness-architect.zip -d ~/.claude/skillsThat installs it everywhere. For one project only, run the same command from that project's root with .claude/skills as the target. Confirm it registered by typing /skills in a session.
Codex.
mkdir -p ~/.agents/skills
unzip ai-harness-architect.zip -d ~/.agents/skillsInvoke it with $ai-harness-architect, or describe your problem and let it match.
Run it
Open your agent and paste any of these.
Help me design a harness for my setup.What should I actually install in Claude Code?My setup feels bloated and I do not know what to remove.How you know it loaded. It asks which agent you use, then works through one question at a time. If it starts listing tools to install before asking you anything, it did not load and you are talking to your agent normally.
The seven questions
One at a time, in plain language, with nothing that assumes you already know what an MCP server is.
Which agent you use. Asked first, because it changes the name of half the components and the file you will be writing to.
The rest of this playbook is below.
Enter your email to read it. You also get one new playbook every week.
One email a week. Unsubscribe any time.
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
| Symptom | Fix |
|---|---|
| Skills menu greyed out in the app | Code execution is off. Settings, then Capabilities |
| It recommends without interviewing | The skill did not load. Type /skills in Claude Code to check |
| The upload is rejected | Use the ZIP file rather than any other extension |
| Installed but not found | It has to sit at your project root, not in a subfolder |
| Recommendations feel generic | Answer the work question with a specific task, not a category |
| It suggested something you cannot install | Say so. The technical comfort answer drives this and it adjusts |
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.
