Every time I hand work to an AI agent — a coding agent, a chat window, whatever — the output quality tracks one thing almost perfectly: how much context I bothered to write down before I started typing the actual request.
So I stopped improvising. Now there are four lines at the top of whatever file or thread I'm working in, and I write them before the first prompt:
WHO: who this is for, and what they already know
DONE: what "finished" looks like, in one sentence
NEVER: the two or three things that must not happen
NEXT: the single next action after this task ships
That's it. Four lines, maybe thirty seconds.
WHO kills the biggest failure mode — the agent writing for a generic reader instead of the specific one. "Senior backend dev, knows our auth stack, has never seen this service" produces different code and different comments than nothing at all.
DONE is the one people skip, and it's the one that saves the most time. If I can't write the finish line in a sentence, the task is actually two tasks and the agent is about to guess which one I meant.
NEVER is where the scar tissue goes. Mine usually reads something like "don't touch the migration files, don't add a dependency, don't refactor anything I didn't ask about." Every line in there exists because it happened once.
NEXT is not for the agent at all. It's for me, forty minutes later, when I come back with the context evaporated. Writing the next action down while I still have the whole problem loaded is the cheapest thing I do all day.
The interesting part is what happened to the prompts themselves. They got shorter. Once the constraints live above the task, the request is just the request — no more paragraph of throat-clearing about what I really meant. And when the output is wrong, the diff between what I got and what those four lines say is usually the whole diagnosis.
I don't think the specific four are magic. WHO/DONE/NEVER/NEXT is just what survived a few months of trimming. The general shape — a tiny fixed header you write before delegating, in the same place every time — seems to be the thing that matters.
Which is why I'm curious about yours.
- Do you write anything down before you delegate to an agent, or do you go straight into the prompt?
- If you have a header like this, what's in it that isn't in mine?
- And for the people who tried structured prompting and dropped it — what made it not worth the thirty seconds?
Genuinely asking. I've got a sample size of one here.
Top comments (2)
NEVER is the line I'd defend hardest and also the one I trust least, because it only holds while the agent is still reading it. Everything on that list is there because it happened once, which makes it a real constraint, which is exactly why it deserves better enforcement than a header.
The ones that matter I'd want moved into things that fail rather than things that warn. A migration touched outside the migration flow shouldn't produce a note, it should not build.
What's in mine that isn't in yours is a budget line: what this is allowed to spend, in tokens and in blast radius. And on NEXT, I'd write down who has to be told, not just what happens next. Forty minutes later I remember the task and not the person waiting on it.
That budget line is the one I keep leaving off and then regretting. Tokens are easy to write down; blast radius is the one that actually changes what I let the agent touch.
I also like forcing NEVER into something that fails closed. A header is a hope. A build gate is a contract. Same for “who has to be told” on NEXT — I’ve burned people by remembering the task and forgetting the person waiting on it.
Stealing both: budget (tokens + blast) + named notify on NEXT. Thanks for sharpening the list.