You ask the agent for a login screen. You get a login screen, a password-reset flow, a “remember me”
checkbox, a settings page and a new AuthProvider abstraction “for future flexibility”. All of it
compiles. None of it was the plan. Reviewing it takes longer than building the screen would have.
This is scope creep, and agents are very good at it. The cheapest defence we know is a won’t-do list.
Why agents over-build
It is not malice, it is helpfulness. An agent trained to be useful fills gaps it sees: a login screen usually has password reset, so add it. Without a boundary, the helpful move and the scope creep are the same move.
You can’t fix that by asking the agent to “keep it simple” — simple is relative. You fix it by naming the things that are out.
What goes on the list
For each version, write the features you are deliberately not building, each with a short reason:
## Won't do (v0.1)
- Full git client (diffs, branches, merges) — other tools do this well; we only commit & push.
- File watcher — manual refresh is enough until people ask.
- Mobile app — the workflow happens at a desk.
- Drag and drop between columns — buttons with undo are faster to build and to use.
- Editing tasks inside the app — the repo files are the source of truth.Good entries are specific (a feature, not a vibe), tempting (something you or the agent would plausibly build) and justified in one line.
Make the agent follow it
A list the agent never reads does nothing. Put it in the plan file the agent reads at the start of every session — see Memory lives in files — and add one instruction:
If the task seems to need anything from the "Won't do" list, stop and ask me.
Don't build it, don't add a placeholder for it, don't add an abstraction to make it easier later.The last sentence matters. “Future flexibility” abstractions are scope creep in disguise.
The list is a decision record
The reasons are the valuable part. Three months later, when you (or an agent) propose adding a file watcher, the list tells you why you said no and what would have to change for a yes. You reopen the decision on purpose instead of by accident.
When a version ships, review the list: some items graduate into the next version’s plan, some stay out. This is part of carrying work forward between versions.
Signs your list is working
- Diffs from the agent are smaller and easier to review.
- You finish phases instead of widening them — see phases, not to-do lists.
- Versions ship with a clear one-line promise.
- You catch yourself saying “that’s on the won’t-do list” to your own ideas.
Where ShotMatic fits
ShotMatic itself is built this way — its spec has a “deliberately left out” section that is as long as the feature list, which is why it stays a small, fast app. And because it reads your repo’s own plan and progress files, the won’t-do list sits right next to the phase and next step your agent works from.
