Writing good tasks

Brief Sai the way you would brief a capable new hire. A good task names what to read, what to produce, where to put it, and what a repeat run should do.

Name four things

A task description works best when it names what to read, what to produce, where to put it, and what a repeat run should do about items it has already handled. Here is a real weekday brief:

Every weekday morning, produce a short daily priorities brief and save it to artifacts/daily-brief-[YYYY-MM-DD].md.

1. Read today's Google Calendar events across all calendars. Note times, attendees, and any pre-read links in the event description.
2. Scan the Gmail inbox for the last 2 days. Ignore notification and newsletter noise. Pull out real requests, document comments, and threads awaiting a reply.
3. Search Slack for recent mentions and unanswered asks, reading the surrounding thread for context.
4. Synthesize a brief with today's schedule as a table, a numbered list of top priorities, each with its source and what is being asked, and a short “also worth a glance” section.

Do not invent to-dos. Every item must trace to a calendar event, an email, or a Slack message. If a source is unavailable, say so rather than filling the gap.

Keep the range bounded

Point Sai at a defined slice of work: “check the last 2 days of email”, not “scan all historical inbox threads”. Bounded tasks finish faster, use less computer time, and are easier to check.

State the rules that must hold

Say what must never happen, and what to do when information is missing. Rules such as “do not invent to-dos” or “flag only, do not reject anyone” keep results trustworthy on runs you are not watching. If you correct Sai on the same point twice, turn that correction into a skill.

Start from a task that already works

Not sure where to begin? Open the To Automate section and look at the featured starter tasks. They cover office work, PR, sales, everyday personal tasks, solo founders, research and more. Run the one closest to your job, watch what it does, then change it: swap the source, change the schedule, adjust the output format, until it is yours. Starting from something that works teaches you what a good task description looks like faster than documentation does.