Write a useful request
A useful request says what should be true when the work is complete. Add the information that changes the answer: audience, source, deadline, constraints and approval boundaries.
You do not need a special command language. Plain language is enough.
Include the details that matter
| Detail | Example |
|---|---|
| Outcome | Prepare a customer follow-up draft. |
| Source | Use today's call notes and the current proposal. |
| Audience | Address the customer's operations lead. |
| Constraint | Keep the scope and price unchanged. |
| Deadline | Have the draft ready before tomorrow's review. |
| Boundary | Show me the draft before sending. |
Draft a follow-up to the operations lead using today's call notes and the current proposal. Summarize the agreed next steps, keep the price unchanged, and flag any request outside the proposal. Show me the draft before sending.
Explain ambiguity
Names, dates and phrases such as “the latest version” can refer to several things. Include the customer, project, date range or document link when it helps identify the right record. For scheduling, include your time zone and the people who must attend.
If you do not know a fact, say so. Ask Milo to identify the missing information rather than fill it in.
Refine the same deliverable
Follow up with the specific correction you need:
Keep the three next steps. Replace the opening paragraph with a shorter summary, and leave the delivery date conditional on approval.
After a revision, check the full result. A useful edit should preserve the other constraints you already supplied.