How to write a Dots task brief
A reusable structure for ongoing work: outcome, sources, actions and delivery.
Define the output contract
Write the deliverable first: a file, decision memo, table or change list. Specify its audience, fields and destination. “Help with the project” leaves the result open; “maintain a table of owners and changed deadlines” defines a usable artifact.
Name sources and precedence
Give direct links and explicit scope. When two sources conflict, say which is authoritative and ask for the conflict to be shown. Preserve an identifier for each item so a later run can update rather than duplicate it.
Separate cadence from notification
The work may run daily while messages arrive only when something changes. Write the check frequency and notification criteria separately. Include the time zone, end date and the destination for urgent decisions.
A brief worth reusing
Give the brief a version and keep two example outputs: one ordinary case and one case with a missing input. Revise the instruction when repeated feedback reveals a pattern. A useful template carries the decisions you would otherwise repeat in every conversation.