I Built a Claude Code SkillThat Tells Me Not to Build Things

I have more ideas than weekends. The pipeline from a thought to a thing I can actually poke at is the same every time: get the idea out of my head, work out whether it is worth the days, scaffold it, cut it into chunks, build. I had been retyping that as prompts, and getting a slightly different process every time.

The part that kept failing was the second step. I would open a session, paste four paragraphs of enthusiasm, and ask whether it was worth building. I never once got a no. I would get a plan — a good plan, usually, with phases and a stack and a sensible order.

That is not the model being agreeable. It is the question being badly posed. By the time the idea reaches the agent it has already been framed as a thing to build, written by someone who was excited enough to write it down, with no stated cost to weigh it against. There is nothing in the context that could produce a no. Asking harder does not help. "Be critical" gets you a plan with a risks section.

The failure mode this produces is expensive and quiet. You do not lose a day to a bad idea. You lose three days to a fine idea that needed a paid dataset you were never going to buy, and you find that out in milestone four when the free tier runs out.

So the design goal was narrow: make it possible for the process to return "don't build this", and make that verdict come from something other than my mood on the day. Everything else in the skill — the milestones, the roadmap, the context files — is scaffolding around that one requirement. It is called idea-to-mvp, it is a Claude Code skill, it is MIT, and it is about 850 lines of Markdown with no dependencies at all.

Three things about you cannot be guessed, and getting any of them wrong quietly ruins the gate.

Machine. Where your projects live, what OS and shell, which runtimes are actually installed, and whether these projects ever get hosted or just run locally for one person. A scaffold built for the wrong setup burns a milestone before anything interesting happens. Mine says local only, no hosting, Windows and PowerShell with Git Bash available.

Budget. Not a number — two lists. What you already pay for and can therefore use freely, and the hard ceiling for anything new. My budget section says this machine, home internet, Claude Code, a VPN, and then: nothing new by default, a one-off small spend only if it is the single thing standing between the MVP and a real answer, and ask first. It also lists what is explicitly off limits, which for me is paid data and lead databases, paid enrichment APIs, paid hosting, and anything with a recurring per-seat cost.

What counts as value. This is the one people skip and it is the one that matters. The options are direct money, indirect money, reusable capability, open source value, and learning a specific technique. You pick which are real for you and say why. A kind of value you did not list does not count for your projects even if it is genuinely valuable in general. And "interesting" is never on the list, because "interesting" is the word that approves everything.

Optional, and the most useful field in the file: reference projects. Absolute paths to two of your own repos whose layout should be copied. A real repo beats any written recipe, because the agent can go and read how you actually lay things out rather than following a description of it.

The uncomfortable design consequence is that a lazy profile produces a gate that approves everything, which defeats the entire skill silently. There is no way to detect that from inside. So the README says, in the loudest formatting GitHub allows, to read the profile the agent writes for you before trusting a single verdict it produces.

A milestone is three to five verifiable subtasks. That is roughly one conversation of real output, which makes it one commit and one roadmap update. If it will not fit in five, it splits, and the rule says explicitly that there is no exception for "but they are all small". Four to seven milestones gets you to MVP. If your plan needs twelve, the MVP is defined wrong, not the milestones.

The load-bearing word is verifiable. Every milestone carries a Verify line that says how you will know it worked — a command that runs, a test that passes, an artefact you look at. If you cannot write that line, the milestone is not defined yet. It is a wish with a checkbox next to it, and an agent will happily tick it.

The unproven part goes into milestone two or three, never last. This is the ordering rule, and it is the one I would keep if I could keep only one. The natural instinct is to build the boring, certain infrastructure first because it feels productive, and to leave the part you are unsure about until the end because it is hard. That ordering guarantees you discover the dead end on day three with three days of scaffolding built on top of it. Inverted, you find out on day one, when the sunk cost is an afternoon.

There is a third rule that only applies to a specific class of project, and it took a real failure to arrive at. For projects whose entire value is the quality of an output — a score, a ranking, an enrichment, a scrape's completeness — the final milestone iterates for real: a named metric, the exact command that measures it, a baseline taken before anything changes, a target, and a hard cap of five iterations.

The cap is there because "keep improving it" has no stop condition, and an agent asked to keep improving something will always find something to say it improved. What you get without a cap is a confident 10/10 on a metric nobody measured. What you get with one is a number, and a file explaining why it is that number.

When the build phase hits something that actually needs me, it writes an OPEN entry into questions.md with the options laid out and a recommendation attached. Then it parks only the subtasks that entry blocks, and finishes the rest of the milestone.

I answer inline, underneath the question, whenever I next look. The next run picks up the answer and unparks the work. Nothing is ever guessed on an open question, and nothing ever stalls waiting for one. The asymmetry matters: a stalled session costs you the whole session, while a parked subtask costs you one subtask.

The rule sitting next to it is the one I trust the most, because it is the one that makes the roadmap worth reading at all. Never invent progress. A subtask is marked done only when it ran, or its test passed, or its output was inspected. If something was skipped or half-finished, the roadmap says so in those words.

I want to be careful about what that is. It is a standing instruction reread at the start of every build phase, not a guarantee — nothing in a Markdown file can force honesty out of a language model. What it does buy is a record that is allowed to be unflattering, and on my one full run it took the offer. The roadmap contains a milestone annotated "took three attempts" with what failed each time. It contains a correction noting that a milestone had been written against the wrong pixel target and was measured against a number that no longer applied. It contains a note that a threshold in the first draft was set too high and let a near-duplicate through.

None of that is impressive. All of it is more useful than a clean row of ticks, because three weeks later the clean row tells you nothing and the correction tells you exactly why a constant is the value it is.

The reel passed all six quality checks. The page held the scroll. The question the MVP was built to answer got a yes. By every measure the milestone defined, it worked.

The ceiling file opens by confirming that, and then spends most of its length on what the artefact does not show.

"The content is information, not a product." The reference channel this format was borrowed from films a thing you can go and download, so the reel ends with a want. This reel ends with three vulnerabilities and a pricing change. It is genuinely useful and it is not the same emotional shape, and the file states plainly that no amount of typography fixes that.

The sample rests on one day of input. That day's edition was security-heavy, so two of the three chosen stories were the same CVE from different angles and the reel says the same product name twice in thirty seconds. The file notes that the neighbouring project has subject-overlap dedup for exactly this and that this one had none, which is how that became a later milestone.

The narration reads headlines, it does not sell. That was the right call — the page carries the detail and the voice cannot fit sixty-six words of explanation across three stories — but a headline is a statement, not a hook. Four caption rules borrowed from a different channel are listed, and the file explains why most of them cannot apply here: "avoid developer-category words" is unusable when the subject is a CVE in a database tool.

And the line that justifies the whole mechanism: nothing here has been measured against an audience. Every constant in the project is borrowed from a channel filming a different kind of thing. The neighbouring project at least matched real reference footage frame by frame. This one has no reference at all.

I did not write any of that. It is the output of a milestone whose instructions say that an honest ceiling counts as a successful outcome, stated in exactly those terms and stated up front, because the alternative is a fabricated 10/10. A build phase told to keep improving something will keep reporting improvements. A build phase told that a stated limit is a valid ending will sometimes tell you the thing you needed to hear on day one.