Prompting for a Small Feature: Requirements Before Code

“Add a leaderboard” sounds like a feature, but it hides decisions. Which players appear? Can scores change? How are ties handled? Is it local or shared? If I ask for code before deciding, the model chooses those rules for me. Once requirements are clear, Break a Large Request Into Smaller Prompts keeps the work in checkpoints instead of one oversized request.

Start with a short prompt: I want a local leaderboard for a single-player browser prototype. List the user-visible actions, data fields, and edge cases. Ask only questions whose answers would change behavior. Do not generate code yet. After reviewing, I might approve: each score has a player nickname, points, and timestamp; higher points rank first; ties keep the earlier score first; only the ten best scores appear. Those are decisions, not technical instructions.

I ask AI to turn the approved behavior into tests: Write six pass/fail scenarios for the approved rules. Include a tie, duplicate nickname, empty leaderboard, and a new score that pushes an older score out of the top ten. Label any assumption not settled by the rules. I review the scenarios before generating code. If the model assumes network sync, I reject that assumption for the local prototype.

Now I can request the ranking function, then storage, then UI. Each slice has an acceptance check. This reduces the chance of receiving a large feature that looks complete but does not satisfy the actual rules. Try it: Pick a small feature. Write one user action, one edge case, and one success criterion. Ask AI to expand these into a behavior checklist before it writes code. Keep only criteria you can test. Keep learning: Break a Large Request Into Smaller Prompts, A Better Code Review Prompt Uses a Diff and a Risk Checklist, and Structured Outputs: When a Schema Beats More Prompt Words.