Run this over your next build before anyone writes a line of it.
Colette Leung is Head of Total Rewards at Chainlink Labs. She spent about a year handing requirements to an external developer while they replaced a long term incentive programme that used to live in Google Sheets. The system that came out of it now runs 1,200 users, with new grants and settlements going out every month.
She came out of it with a test she now runs on herself before anything gets built, and it works the same whether the thing on the other end is a developer or a model.
Your requirement is probably stupid, and it's probably too long.
1. Write it long first
Write the requirement the way it arrives in your head. Every option, every edge case, every person you're trying not to annoy. Don't edit while you write.
Most comp requirements arrive at somewhere between 400 and 1,500 words. That's normal, and it is not yet a requirement. It's a wish list with a job title on it.
2. Cut it in half
Halve it. Trimming a tenth off the edges does nothing.
Go through and mark every line. Either the build is useless without it, or it's a preference you'd defend in a meeting.
If you can't find half, you haven't understood the problem yet.
3. Answer these four before you build
What decision does this change? Name the decision and the person who makes it. A build that doesn't change a decision is a dashboard nobody opens.
What does the person do differently? An answer that amounts to looks at it means you've described a report and called it a build.
What's the smallest version that would prove it? Usually one scenario, one population, one quarter. Build that and nothing else until it's wrong in a way you can see.
What are you pretending you know? Every requirement carries an assumption about the data underneath it. Write the assumption down as a sentence.
4. Stop adding
The failure Colette names is the one that catches everybody. Give a developer too much context and keep piling change requests on top, and the code quality shatters. Overload a prompt and exactly the same thing happens.
So once the halved requirement is agreed, changes go in a list for the next version instead of into the current build.
5. Decide how you'll know it works
Before anyone builds, write down the check. One scenario where you already know the right answer, calculated by hand. The finished thing has to reproduce it.
For anything touching pay, that check is not optional. A tool that models equity or prices a role can be confidently wrong.
6. The two ways this still goes wrong
You fall in love with the solution. The build becomes the project, the project becomes a product, and somewhere back there was a business problem nobody has looked at in weeks.
You automate something stupid. A bad requirement built well is worse than no build, because now it's fast, it's repeatable, and it has an air of authority it hasn't earned.
The same cut, applied to the model
Caveman is an open source skill for coding assistants, built by Julius Brussee, and it runs step two on the model rather than on you. The pleasantries and the hedging come out of what the model writes back, while code and error messages stay exactly as they were.
His own benchmark puts the saving at 65% of output tokens on average across ten coding tasks, with a spread from 22% to 87%. Whole session savings land lower, because the rules cost input tokens on every turn.
It belongs at the end of a requirements brief because a shorter answer is one you can check, which is the same reason a halved requirement survives contact with a build.
Install it with npx skills add JuliusBrussee/caveman, or read what it does first at github.com/JuliusBrussee/caveman.
In a nutshell
Assume your requirement is stupid. Assume it's too long. Cut it in half, rebuild it from first principles, and only then let anyone touch it.
Colette's full conversation is on Range Podcast, where she walks through the vesting simulator she built herself and the year five cliff it put on screen.