Great prompts in Evonx describe outcomes, constraints, and users — not just UI vibes.
There is a lot of advice about prompting that amounts to incantation: magic phrases, role-play framings, threats. Very little of it survives contact with real product work. What actually separates a prompt that produces something useful from one that produces something decorative is much more boring, and it is mostly about information you already have and did not think to include.
Name three things
The user and their job. Not a persona — the actual person and the actual thing they are trying to finish. "Warehouse staff scanning returns at the end of a shift" carries a dozen implicit requirements: they are standing up, in a hurry, possibly on a phone, and doing the same action repeatedly. None of that has to be spelled out once the user is named.
The constraints. Stack, existing conventions, brand, deadline, what must not change. Constraints are not limitations on the output; they are most of the specification. An agent with no constraints will pick reasonable defaults, and reasonable defaults are exactly what a mature product cannot use.
A previewable next step. End with something you can look at and judge. This keeps the loop tight and, more usefully, forces you to be concrete about what "progress" means here.
The same request, twice
The vague version is not bad because it is short. It is bad because every important decision has been left to the agent, which means you will disagree with several of them and have no basis for saying why. The concrete version has already made those decisions; the agent is executing rather than guessing.
Patterns that hold up
- Describe the outcome, not the widget. "Ops leads should catch late orders before the customer calls" leaves room for a better answer than "add a red badge to the orders table".
- Say what must not change. Explicitly protecting the working parts is faster than reviewing whether they survived.
- Give one real example. A single concrete record — a real order, a real invoice, a real edge case — pins down more schema than a paragraph of description.
- Correct against the preview, not the code. "The overdue ones should be at the top" is a better correction than a suggested implementation, and it is one anyone on the team can write.
- Keep one thread per outcome. Mixing two goals in one thread makes both harder to review.
What not to bother with
You do not need to assign the agent a persona, promise it a reward, or restate your instructions in capitals. You do not need to describe your database schema if the repository is connected — it will read the real one, which is more accurate than your description of it.
You also do not need to get the first prompt perfect. The loop is short by design: send something reasonable, look at the preview, correct in plain language. Two rounds of that beats one carefully engineered prompt almost every time, because the second round is informed by something real.
One genuine exception: it is worth saying when you are uncertain. "I am not sure whether this should be a separate page or a panel — show me the simpler one first" gives the agent something useful to do with the ambiguity, rather than resolving it silently in a direction you may not have chosen.
The underlying habit
All of this reduces to one thing: say what you actually know. Most unproductive prompts are unproductive because the author knew the user, knew the constraint, knew what good would look like — and wrote none of it down, expecting the agent to infer it.
Do that consistently and the agent stays productive instead of decorative.