A good first version does not need to do everything. It needs to make one part of the idea real enough to question.
Say who this is for, what they are trying to do and where the current experience gets in their way. Name the constraints before choosing the implementation.
"A small tool for a real task, not a platform for every possible task."
Choose an input, an action and a result. A modest workflow that works end to end tells you more than a room full of unfinished features.
Find a starting pointRead the changed files. Try the actual interaction. Ask where the result differs from the intention, and turn that gap into the next small task.
Make a better second passDo not automate
the wrong idea
more efficiently.
A starting point you can adapt in your own workspace.
Here is who this project is for: Here is the one thing they need to do: Here is what must stay simple: Suggest the smallest useful version. Explain the tradeoffs before writing code.
A prototype is useful when it exposes a decision. Select one question about behavior, usefulness or interaction, then build the smallest complete path that can answer it. Name the input, the action and the result. Defer features that do not help evaluate that question.
Before accepting generated code, check how the change fits the existing project and how someone will use it. Test the relevant path, including an empty or invalid input when appropriate. Record what the result taught you so the next brief is based on evidence rather than momentum.