action-items

Action items

Use this skill to update /action_items.md in dream_notes. It is the private list of important tasks, commitments, and activities you are helping the user move forward.

Use cloud_threads.read_dream_notes to read the file and cloud_threads.write_dream_notes to update it.

The main assistant decides what to do for the user. If you're the native memory subagent, use the findings, the parent thread when available, and existing notes to decide which action items to add, update, or close. Make and verify the changes. Dreamers may read the list and suggest changes, but they don't edit it.

When assigned to maintain memory, record the next useful step. Carry it out only if the main assistant also assigns you that work.

Objective of /action_items.md:

• /action_items.md contains a list of the user's important ongoing activities – open tasks, commitments, deadlines, scheduled checks, admin, to-dos. You use these items to provide proactive reminders and help for the user, and as a way of tracking progress on the user's ongoing life tasks.
• User requests, connected sources, and Dreamer reports can all surface possible action items. Track relevant open work even if the user explicitly hasn't mentioned it, hasn't asked you to work on it or you aren't starting it immediately.
• You are also responsible for cleaning up action items when they are complete, so that this list remains high-signal. For example, if an expense report shows four items needing information from the user and five awaiting Finance review, track the four as needing the user and don't treat the other five as work for the user. Leave out unrelated team follow-ups with no clear owner.

Adding to and updating /action_items.md:

• Start with [] only if the file is confirmed missing or empty. Do not replace a file you have not read. Store a formatted JSON array with one object per item, no Markdown or code fence.
• Read all of /action_items.md before writing; a write replaces the whole file. Set limit_chars to 100000 for each read. If has_more is true, continue from next_offset_chars. If you can't read the whole file, don't write. Preserve any items you aren't updating or removing.
• Add or update an unresolved task, commitment, or deadline that matters to the user, a concrete opportunity to help with something they care about, or a meaningful change to an existing task. Save it as todo even if work isn't starting now or one detail still needs checking. Record what is known and the next useful step. If ownership or status is uncertain but the outcome matters to the user, make the to-do about checking that. Record an unanswered request as a request, not an accepted commitment. Tracking it does not authorize an external action or require messaging the user. Leave out unrelated or purely speculative work. Link the original source or a supporting memory note.
• If there is an existing item with the same outcome, update that item, keeping its ID and creation time. Incorporate new evidence about its status, blocker, deadline, or outcome; close it when the evidence shows it was completed or cancelled.
• Use these eleven fields on every item, in this order:
  • id: A unique, stable, readable ID like choose-boston-wedding-flight. Use lowercase words separated by hyphens; add a meaningful detail if two names would otherwise match. Preserve an existing ID when converting older items.
  • name: A short, plain name like Check Iberia claim status.
  • emoji: One emoji that fits the task, like 🧾 for a refund or ✈️ for a flight. Keep it out of the name and description. Use null if no emoji fits.
  • description: A short preview for the user. Add context or explain the outcome without repeating the title, like "Process a refund from your cancelled flight on September 12, 2026." Use full calendar dates with the year, not "today," "tomorrow," "next week" or similar wording. For a specific time or cutoff, show it in the user's known time zone and name the zone, like "September 16, 2026 at 3 p.m. PT." If the user's zone is unknown, use the source's stated zone and say the user's zone is unknown. If neither is known, mark the time zone unconfirmed. Don't invent a time for a date-only deadline. Keep the working details in notes.
  • notes: One free-form text string with the detail you need to continue the task. Include useful background, what has been checked or done, decisions, open questions, who or what is pending, deadlines, next steps, and links to original sources or your memory notes when relevant. Write as much as the task needs; paragraphs or line breaks are fine. Use the person's actual name when you know it, including the user's. Otherwise say the user or what you know, rather than you. Link to fuller records instead of copying them wholesale. Use the same date and time rules here. If the source's time zone differs from the user's, keep the original time and zone here too. Use "" when there's nothing to add.
  • blocked: true if no useful next step is possible until something changes; otherwise false.
  • blocked_by: A list of IDs of other items that currently block this one. A nonempty list means blocked is true; use [] when there are none. An item can still have blocked: true with blocked_by: [] when the blocker is outside the list. Any ID here must exist and must not be this item or create a cycle.
  • waiting_on: user, assistant, other, or null. Use user when the user owes a reply, decision, or action; assistant when your work or a delegated result is still pending; other for another person, a service, or an event; and null when nothing is pending. Say exactly who or what is pending in notes. If several things are pending, choose the one that matters most for the next step and mention the rest in notes.
  • status: todo, in progress, done, or cancelled. Start at todo; use in progress when work has begun, done when the outcome is confirmed, and cancelled when it is no longer being pursued. Waiting and blocking are separate from status.
  • updated_at: When the item last changed, in ISO 8601 UTC, like 2026-09-15T14:00:00Z. Refresh it only when something actually changes.
  • created_at: When the item was first recorded, in the same format. Set both timestamps to the same time for a new item; keep created_at unchanged afterward.