Intent before form

I’ve put a small thing on GitHub: anti-slop-spec-driven-workflow. It’s five Agent Skills, MIT licensed, with no dependencies or setup script. This post is the short version of why I made it.

The itch

Making something is mostly a matter of turning intent into form. You start with a fuzzy shape in your head, push the work around until the two match, and eventually the intent becomes part of the thing itself. That’s why you can read good code and feel what the author meant.

Generative AI makes that link very easy to lose. It can produce an enormous amount of form from almost no intent at all. Turn up with a vague idea and you get a confident, plausible-looking implementation, plus a little voice saying hmm, I guess that looks right.

Form with no intent behind it is what I mean by slop. AI didn’t invent it. We managed slop perfectly well on our own for decades. What it removed was the last barrier to producing it at volume.

That’s the actual cost of vibe-coding your way through a feature. It feels fast, but some of that speed comes from skipping the intent step. What you get is a feature nobody fully understands, edge cases nobody thought about, and an architecture that folds the first time you lean on it. The form arrived; the intent never did. You settle the bill later, in debugging, with interest.

What it does

The whole thing is one linear pipeline:

Plan → PRD → Issues → Tasks → Code → Review → Audit

Each step is a skill, each skill produces a file, and each file is a checkpoint where you stop and read something short enough to actually read.

The shape it enforces is always the same, and it’s the only real trick here:

AI produces something → you review it with full context → it gets created

The AI accelerates production. The intent stays yours, and you still get to check that the result matches it. Each artifact makes that intent legible: it’s the thing you’d hand a teammate alongside the generated code so they could understand what you meant.

A few details matter to me more than the rest. write-a-prd interviews you rather than guessing, and keeps asking about failure modes until you’ve answered “what if this breaks?” for every happy path. Issues come out as tracer bullets—thin slices through schema, logic, API and UI—instead of horizontal “do all the database work” lumps.

Tasks are sized to fit one focused session, because long sessions drift and the model starts making decisions based on what it already did rather than what the task actually requires. And code-review has a dedicated pass just for operation ordering, which is where I catch the most bugs: AI has a particular talent for doing all the right things in the wrong sequence.

What it isn’t

This isn’t the fastest way to get started, and I’d rather say that plainly than have you find out halfway through. The planning and PRD steps take real time up front. It only pays for itself if you believe that thinking before coding beats debugging afterwards—and, honestly, we’ve all had days when jumping straight into the code felt much more appealing.

It also isn’t a replacement for judgment. It captures and checks your intent; it can’t generate it for you. The model will produce reasonable-looking form at every single step, which is why the review checkpoints are mandatory rather than encouraged.

And it isn’t all-or-nothing. code-review and final-audit work standalone on any codebase, so you can steal the back half and ignore the rest. I won’t know.

None of this rests on the idea that AI is bad at writing code. It isn’t, and it’s getting better at producing polished code every few months. But the intent still has to come from a human, and no amount of model progress changes that.

The README has a full tutorial that ships one tiny feature end to end, from brain dump to audit. It’s a “star a todo” feature, small enough to read in full and big enough to touch every layer.

Credit where it’s due: the idea took shape after this article by noperator and this antirez video. Go and read and watch those too; they’re both worth your time.