Ask for work
State the outcome. Add the context and limits that affect the work.
A useful request
Section titled “A useful request”A request can include four parts:
- Outcome. State what must be true when the work is complete.
- Context. Name the repository, document, customer, date range, or system to inspect.
- Limits. State what the agent must not change or publish.
- Proof. State how to verify the result.
For example:
Find why workspace invitations fail for addresses outside the company domain. Use the testing environment. Fix the cause, add the test that would have caught it, and open a draft pull request. Do not deploy or merge.
Give it the source material
Section titled “Give it the source material”Attach a file, paste a link, name a connected record, or point to a synced source. State which source is authoritative when two sources can disagree.
If access is missing, ask the agent to connect the service. Use the connection or credential control that it returns. Do not paste secrets into the conversation.
Set decision boundaries
Section titled “Set decision boundaries”State which actions the agent may take. Set clear limits for work that can affect customers, production, money, or another person.
Diagnose the production alert and give me the evidence. Do not change production.
Update the draft in Notion. Do not send it to the customer.
Ask for evidence
Section titled “Ask for evidence”Name the proof you need. Examples include a test result, a browser check, a fresh query, a source link, or the exact state after a change.
Use the same conversation to refine the result:
Make the report shorter. Keep the table and remove the forecast.
Check the pull request again after CI finishes. Fix only failures caused by this branch.
See Recipes for complete requests you can adapt.