Key takeaways

  • The expensive part of working with Claude is not the work. It is that you have to be there while it happens, catching what it quietly skipped.
  • This skill sits on top of Claude Code’s own /goal and adds four things it does not do on its own: alignment, adversarial audit, proof, and an exit written as a file rather than left to a judgement call.
  • It runs for hours unattended. You are touched twice: the interview at the start, the evidence at the end.
  • Four auditors on four different angles, plus a web search, up to ten rounds. A contradicted external claim beats all four auditors agreeing.
  • No screenshot of the real thing working, no completion. A passing test is not a working page.
  • It replaces roughly thirty separate things you would otherwise have to learn before you could trust any of this, which is the actual reason people stall.
  • This is the machine underneath a one-person growth stack. Not because one person is faster, but because the work refuses to report itself finished until it is.

A Claude Code skill is a markdown file that teaches Claude a repeatable procedure. The Build a Goal skill teaches it to convert a piece of work into an unattended run: it interviews you until it knows what you meant, writes a plan and a trigger that carry the proof requirement, then loops build, prove and audit with five agents per round until the work is demonstrably done or provably impossible.

A founder told me something last week that I have not been able to put down.

He is not technical. He had already used Claude Code to build most of an internal system, and it looked finished. His problem was not that it was broken. His problem was this:

“I told Claude to go build it and Claude went and built it. Is it set up right? I do not know. I have all these folders sitting on my desktop and I think they’re right, but I do not even know if they’re right. So the lack of confidence is where I get stuck, because I do not know if I am building the right thing, which makes me just not take any action at all.”

That is the real tax, and it is not a coding problem. Claude will build you almost anything. What it will not do is tell you the truth about whether it worked, unprompted, from an angle you did not think to ask about.

So you stay in the room. You ask, it says done, you go and look, you find the gap, you ask again. It says you are right, it missed that. You find another one. That cycle can eat days, and every single round costs your attention, because you are the quality gate.

I hate being in that loop. That is the whole origin of this skill. I want to say the thing, walk away, and have it come back finished, so that if I am unhappy the argument is about the outcome and not about whether it actually did what it said.

There is a second reason, and it is the one that pays my rent. I run a full marketing stack for other people on my own: offer, funnel, pages, tracking, lifecycle, paid. An agency staffs that with five. The only way one person holds it without the quality quietly rotting is if the work stops needing me to check it. That is the whole operating model, and this skill is one piece of it.

What /goal gives you, and where it stops

Claude Code has a feature called /goal. You attach a condition, and every time the model tries to end its turn the harness checks that condition. The turn does not end until it holds. It is the difference between a model that stops when it feels finished and a model that stops when a rule says it is finished.

That is genuinely good, and it is also where the good part stops. /goal will hold Claude to a condition. It will not:

  • work out what you actually meant before it starts
  • attack its own output from angles it did not choose
  • refuse to call something done without evidence
  • reliably notice when the condition has become impossible, because that verdict is a judgement call made from the transcript alone

Those four gaps are the skill. It does not replace /goal, it stands on it.

1. Alignment, before a single hour is spent

Unattended work aimed at the wrong target is worse than no work, because now you have hours of confident output to unpick. So nothing runs until the model can describe the job back to you.

The sequence is four steps, and only the first two need you.

Point it at whatever already exists and have it reverse-engineer your intent from the mess. Then have it interview you: twenty open questions, answered properly, until you are both describing the same thing. Only then does the skill write the goal. Then you arm it and go away.

The interview is the step everybody skips, and it is the one that pays for the other three. It is also the cheapest possible moment to discover you and the model disagree.

There is a shortcut for the interview that is faster than typing: record a screen video and hand that over instead. It reads the frames, so you stop writing paragraphs trying to describe which button you mean.

2. Four agents, four angles, up to ten rounds

Every round, the work gets built, the artifact gets produced, and then it gets torn apart.

Five agents in parallel. Four auditors, two on Fable and two on Opus, each handed the same evidence and a different remit: correctness against the plan, adversarial against the core mechanic, quality as the buyer would read it, and what is missing or silently skipped. Then one web-search agent that only checks external claims, because how an API behaved in training is not how it behaves today.

Then the findings get compressed into one ranked list, and the filter is brutal: can you run the reproduction yourself, right now, and see it? If not, it is discarded and logged as rejected. Agents are confidently wrong, and they are wrong together, so consensus among auditors is not evidence of anything.

That loop runs up to ten times. It runs for hours. You are not in it.

3. No screenshot, no completion

The failure that survives everything else is the one where Claude tests its own work and passes.

It writes a test, the test goes green, it reports done. Then you open the thing and the button does nothing. It tests like a machine, and nobody using the thing is a machine.

So every goal this skill writes names the evidence type up front and refuses anything weaker. For a user interface that means a real browser driving the deployed page and a screenshot of it working. For a pipeline it means a row of data. For a document it means measured command output.

This rule did not come from working with models. It came from running teams, where people also report things as finished. The fix was the same then: ask for the screenshot. If there is no screenshot, it is not done.

You can be specific with it, too. Tell it every button in the interface has to be clicked and produce the same result as the original, except these three, and it will not come back until that is true.

4. An exit it can actually reach

/goal does have an escape hatch. The evaluator returns one of three verdicts, and the third is Impossible: the condition can never be satisfied, so Claude Code clears the goal itself. There is also a circuit breaker that stops the loop if Claude answers several turns running without touching a tool.

The problem is what that verdict is made of. A small fast model reads the transcript, runs nothing, and decides whether a thing is impossible. That is a judgement call, and judgement calls miss.

I have watched it miss twice. Once for six firings. Then, worse, for eight, on a run that had done everything right: 17 of 18 criteria proven, the last one correctly refused rather than forced green, the blocker written down, a rebuilt prompt pasted. Textbook behaviour. The evaluator never called it impossible, because the condition still said “all 18” and the transcript kept showing an agent working. Every firing burned tokens restating the same facts in new words, which reads like diligence and is not.

I went back through the 49 goals I had written before this skill existed. Four of them carried any exit the agent could reach on its own. Four out of forty-nine.

So the skill stops relying on that judgement. Every goal it writes carries a second branch in the condition itself: all criteria pass, or a criterion is proven unreachable, everything reachable is closed, the blocker is written into the plan, and a rebuilt prompt exists on disk at a named path.

That turns the exit from an inference into a fact. The evaluator no longer has to decide whether something is impossible. It has to check whether a file is there, which is the one thing it is reliably good at. The handback is a success state, not a failure, and the run ends honestly instead of politely looping while you are asleep.

What it actually replaces

I have been teaching my wife to work in Claude Code. I started writing the checklist of what you have to understand before any of this is safe: where memory lives, why each folder needs its own instructions, what a pull request is and why you never push to main, what an uncommitted file is, why a worktree left open breaks the next session, which environment things get deployed to. I got to about thirty items and realised the honest answer was “roughly ten hours of teaching, and you will still be nervous”.

The skill absorbs most of that. Not by explaining it. By being the thing that does it correctly whether or not you know it is happening.

That is why the founder’s problem is a skill problem and not a training problem. He does not need to become technical. He needs the run to come back with proof, so the question “is it right?” has an answer that is not a feeling.

How I actually use it

Two goals, back to back. The same shape I use on client work, which is what the case studies are made of.

The first one audits. Point it at whatever exists, have it reverse-engineer what you were trying to do, and hand you the gaps. The second one implements, with the answers from your interview baked into the plan.

Between them, you talked for about twenty minutes. After that, you are waiting rather than working.

Run the skill inside a goal

Yes, recursively. It is the fastest way to see the loop work, because the artifact being audited is small enough to check by hand.

The prompt is in GOAL-PROMPT.md in the repo, ready to paste. It makes Claude write the plan and the trigger, then hold both against the two-branch success block and the reachability of every criterion, until two consecutive audit rounds come back empty.

Its sibling, Safe to Close, is the one that decides whether the session it all ran in is actually finished, or whether there is unpushed work about to die with the window.

What this has to do with hiring one person instead of five

An agency puts five people on a growth stack because the work genuinely needs five kinds of attention. Someone owns the offer. Someone owns the funnel. Someone owns tracking, which nobody enjoys. Someone makes the creative. Someone is supposed to be reading the numbers.

One person can hold all five, but only under one condition: review cannot be the bottleneck. If every piece of work needs me to open it, click through it and find what was skipped, then my attention is the ceiling and the fifth thing always gets the worst of it. That is how solo operators quietly become worse than the agency they replaced.

So I did not automate the thinking. The offer, the funnel maths, the guardrails, reading why a winner won and deciding what to brief next: all of that is still mine, and it is what anyone is actually paying for. What I automated is the part where I have to verify that a thing was done. The work arrives with the screenshot attached, or it does not arrive.

That is also what makes revenue accountability survivable. You cannot be accountable for an outcome when “done” is a claim someone made about their own work. It has to be a fact you can look at.

The skill is free and public on GitHub, MIT licensed. It writes the plan and the trigger and hands them over. It does not arm the loop for you, because that part spends real money and the decision is yours. If you would rather someone else ran the stack this way on your account, that is the day job.

Get the skill on GitHubSee how I run a full stackWork with me 1-on-1

How do I run Claude Code for hours without watching it?

Align first, then hand it a condition it cannot talk its way out of. This skill interviews you until it can describe the job back, writes a plan and a trigger with the proof requirement built in, then arms Claude Code’s /goal loop with four auditor agents and a web-search agent tearing the work apart every round, up to ten rounds, until the thing is provably working.

What does the Build a Goal skill do?

It turns a piece of work into a run that finishes without you: alignment by interview, a plan and trigger that name the evidence type up front, and an audit loop of five agents per round that only ends when the criteria are proven or the goal is shown to be impossible.

How is that different from just using /goal?

/goal keeps Claude working until a condition holds, which is genuinely useful and where the good part stops. It does not align with you first, it does not audit its own work from angles it did not choose, and it does not force proof over assertion. It can call a goal impossible, but that verdict is a small model’s judgement read off the transcript, so the skill writes the exit as a file on disk instead of relying on it.

Why does it insist on a screenshot?

Because a passing test and a working page are different claims. Claude tests like a machine and nobody using the thing is a machine, so it will hand you green output for a button that does nothing. No screenshot of the real thing working, no completion. The rule came from running teams long before it was pointed at a model.

Why four auditors instead of one?

Four copies of one review is waste. Each gets a different angle: correctness against the plan, adversarial against the core mechanic, quality as the buyer would read it, and what is missing or silently skipped. Two run on Fable and two on Opus. A fifth agent checks external claims against the live web, because four agents sharing a wrong assumption is the normal case, not the rare one.

What happens if the goal turns out to be impossible?

It hands back. /goal does have an Impossible verdict, but it is a judgement call made by a small fast model reading the transcript, and it misses: I watched a hook fire eight more times after a correct and complete handback. So every goal this skill writes carries a second branch in the condition, closed by a file on disk rather than by an inference.

Do I need to be technical to use it?

You need to be able to answer questions about what you actually want. The skill absorbs the part that usually needs about thirty separate things you would otherwise have to learn first, which is exactly why non-technical founders stall: not the building, the not knowing whether what was built is right.