Skip to main content
Leo does better with a clear outcome than with technical instructions. You never need to know how it is built.

​
The four rules

Describe the outcome, not the implementation.
Show a list of all customers from Odoo with their name, email and total orders. Update it when new customers are added.
not “create a React component with a useEffect that fetches…” One feature per message. Credits scale with the size of the request, and a focused ask produces a better result. Build the customer list, then add the search, then add the detail page. Say where it goes and what it should do. “Add a button” leaves everything open. “Add a Save button at the bottom of the customer form that writes the data back to Odoo and shows a confirmation” does not. Name the system explicitly. Say “from Odoo”, “to Airtable”, “in HubSpot”. With several connections on a project, Leo should not have to guess.

​
Correcting Leo

Point at the specific thing rather than restating the whole request:
The total column shows the unit price. It should be quantity times unit price.
Anything you find yourself repeating in every prompt belongs in Knowledge instead.

​
Patterns that work

A dashboard
A form that writes back
A detail page
A cross-system flow
A scheduled check (see Automations)

​
What does not work

Vague requests (“make it better”), several unrelated features in one message, and contradictory requirements (“simple but with everything”). Leo also cannot know anything you have not told it: your brand colors, your API details, or what your other site looks like.