Write requirements the way you'd brief a capable new teammate: state the goal, the constraints, and what "done" looks like. Agents don't need poetry. They need a clear target, the boundaries they can't cross, and a way to check their own work.
A few things move the needle far more than prompt tricks:
- The goal — best for framing: what should exist that doesn't now?
- Constraints — best for safety: which files, frameworks, or patterns are off-limits?
- Acceptance criteria — best for verification: which tests or behaviors prove it works?
- Context pointers — best for accuracy: where does the relevant code already live?
This is where a plan-first approach helps. Tools like Verdent read your requirements, draft a plan, and confirm the direction before writing code—so a vague ask becomes a checkable set of steps instead of a guess. You catch a wrong assumption in the plan, not after 400 lines land.
Ask yourself before you hit go: if a stranger read this spec, would they build the same thing you're picturing? If not, the gap is in the requirements, not the model.
Keep your first spec short and testable. Tighten it once you see how the agent interprets you—that feedback is worth more than a perfect first draft.
