Odyssey365

View saved version →

---
name: board-briefing
description: Read an Odyssey project board and brief the user on where it stands — progress per list and section, what is done, in progress, stuck, or unassigned to any list, and what to do next. Use when the user asks "where are we on this project", "summarize my board", "what's left on X", "catch me up on this project", or wants a status update to share.
---

# Brief the user on a board

This is a **read-only** workflow. Nothing is changed unless the user asks at the end.

## Steps

1. **Find the board.** Use `list_projects` or `search` with the name the user gave. If several match,
   list them briefly and ask which one.
2. **Read it.** Call `get_project` (no components needed). Use:
   - `items[]` — each item carries `title`, and tasks also `status` (`notStarted` / `inProgress` /
     `done`) and `dueAt` (deadline end). `listTitle` and `sectionTitle` say where it sits, and
     `componentId` groups items that share a list even when the list has no title. `missing: true`
     means the card points at an item that no longer exists.
   - `structure.sections` / `structure.mindmaps` — the user's own grouping. Follow it in the report.
   - `autoFilterLists[]` — lists filled by a saved filter; their tasks are summaries only.
   - `shared` — if present, the board belongs to someone else; mention whose items are whose only
     when it matters.
3. **Open details only when needed.** Titles and statuses are already in `items[]`. Call `get_todo` /
   `get_memo` only for items whose title is not enough to judge (for example a checklist's progress
   or a note that holds decisions). Do not open every item.
4. **Write the briefing** in the user's language, in this order:
   1. One-line status: e.g. "12 of 20 tasks done; the Launch section is blocked on copy."
   2. Per section or list: done / in progress / not started counts and the notable items.
   3. **Needs attention**: tasks in progress for a long time, overdue deadlines, lists that are empty,
      notes that contain open questions.
   4. **Suggested next steps**: at most three, each tied to a specific item.
   Keep it scannable — short bullets, item titles quoted exactly, no raw ids.
5. **Offer, don't act.** At the end you may offer to (a) move or complete items (see the
   `board-kanban` skill) or (b) post the briefing to the board's comment thread.

## Posting the briefing as a board comment

`comment_on_project` notifies the board owner and every member and cannot be recalled, so call it
only after the user explicitly asks. Attach the items you mention with `containItems` instead of
copying their titles into the text, post once per briefing, and keep `content` to plain text.

View saved version →

---
name: board-builder
description: Turn a conversation, plan, meeting notes, or brainstorm into a laid-out Odyssey project board — task lists for things to do, note cards for things to read, grouped into sections. Use when the user says "put this on a board", "make a project for this", "organize this into Odyssey", "save these ideas to my board", or asks to add a batch of tasks and notes to an existing board.
---

# Build an Odyssey board

A board is a canvas of components. Items (tasks, notes) live in their own documents and a board only
**references** them from `itemTile` components. Creating an item does not put it on a board, and
removing it from a board does not delete it.

## Layout rule: the container follows the item

| Item | How to place it | Why |
|---|---|---|
| **Task** | Many tasks inside **one** `itemTile` list | Tasks are scanned and moved through states |
| **Note** | **One** note per `itemTile` card, laid out as a grid | Notes are opened and read one at a time |

A list of twenty notes shows only titles; a grid of twenty task cards is noise. Keep to the table above
unless the user asks for something else.

## Steps

1. **Pick the board.** If the user named one, find it with `list_projects` (or `search`). Otherwise ask
   whether to create a new board; create it with `create_project` only after they agree to a name.
2. **Read before writing.** For an existing board call `get_project` with `includeComponents: true`.
   Reuse its sections and lists (see `structure.sections` and each component's `text`) instead of
   creating duplicates. Never move or restyle components the user arranged by hand.
3. **Draft the outline in chat first** when you will create more than about five items: sections,
   lists, and which items go where. Wait for a go-ahead, then build.
4. **Create containers.**
   - Section (optional grouping frame): `add_project_component` with `type: "section"` and `text`.
   - Task list: `add_project_component` with `type: "itemTile"`, `text` = list title, and `sectionId`
     when it belongs to a section. The section positions it; do not compute coordinates.
5. **Create items straight into their container** — one call each, no separate attach step:
   - Task: `create_todo` with `projectUid` = board id and `attachToComponentId` = the list's id.
   - Note: first create an empty `itemTile` card for it at its grid position (step 6), then
     `create_memo` with `text` (the body), `projectUid`, and `attachToComponentId` = that card's id.
   Existing items are added with `update_project_component` using `mode: "append"` and `containItems`.
6. **Place note cards as a grid** by giving each card `size: {width: 400, height: 220}` and an explicit
   `offset`: 5 columns, gap 40, starting below the lists (for example `dy` 560). Card `i` goes to
   `dx = (i % 5) * 440`, `dy = 560 + floor(i / 5) * 260`. Cards cannot be narrower than 400.
7. **Tidy only boards you just made.** If the board was new and has no note grid, call `tidy_board`
   once at the end. Do not call it after placing a grid (it re-flows the grid) or on a board the user
   arranged by hand.
8. **Report back** in chat: the board name, each section/list with item counts, and anything you
   skipped. Do not paste raw tool output.

## Guardrails

- A call that names a missing component or item fails and creates nothing; fix the id and retry
  rather than re-creating items (an `attachError` in a success response means the item exists — do
  not create it again).
- On a board shared with the user (`shared: true`), you can add only the user's own items, and a list
  can be edited only with `mode: "append"` or `"remove"`.
- Deleting components (`delete_project_component`) or items needs an explicit yes from the user.
- Write item titles in the user's language, short and actionable ("Draft landing copy", not
  "Landing copy things").

View saved version →

---
name: board-kanban
description: Work an Odyssey project board like a kanban — move tasks between lists (for example To do → Doing → Done), mark tasks complete, add new tasks to the right list, and take items off a board. Use when the user says "move X to done", "I finished Y", "start working on Z", "add this to the backlog list", "clean up the Done column", or reports progress on items that live on a board.
---

# Move work across a board

On an Odyssey board a **list** is an `itemTile` component whose `containItems` references tasks and
notes. Moving an item between lists is a change to two components; completing a task is a change to
the task itself. Keep both in step.

## Steps

1. **Load the current board.** `get_project` with `includeComponents: true`. Map each list's `text`
   (its title) to its component id, and each item to the list that holds it. Resolve the items the
   user named by title; if a title matches more than one item, ask.
2. **Confirm the plan in one line** when more than three items change, e.g.
   "Move 4 tasks from Doing to Done and mark them complete?" Single, clearly named moves need no
   confirmation.
3. **Apply each change.**

   | User intent | Calls |
   |---|---|
   | Move between lists | `update_project_component` on the source list with `mode: "remove"`, then on the target list with `mode: "append"`, both with `containItems: [{uid, type}]` |
   | Mark done | `complete_todo` (it records the completion on the timeline). If the board has a Done list, also move the task there |
   | Start working | `update_todo` with `status: "inProgress"`; move it to the Doing list if the board has one |
   | Add a new task to a list | `create_todo` with `projectUid` and `attachToComponentId` = that list's id |
   | Take off the board | `update_project_component` with `mode: "remove"` — the task itself still exists |
   | Delete for good | Ask first. Then `delete_todo` / `delete_memo` in addition to removing it from the list |

   Always use `mode: "append"` or `"remove"` for lists. `replace` rewrites the whole list and silently
   drops anything you did not include; on shared boards it is refused.
4. **Verify.** Re-read with `get_project` when you changed more than a few items, and fix any list that
   does not match what you reported.
5. **Report** in the user's language: what moved where, what was completed, and anything you could not
   do (for example another member's item on a shared board that the user cannot edit).

## Guardrails

- "Remove" is ambiguous. Ask whether the user means off this board or deleted everywhere.
- On a shared board, edit only the user's own items unless the response shows `canEditItems: true`.
- An item can be on only one shared board at a time. If a call is refused for that reason, tell the
  user and ask before retrying with `moveFromOtherSharedBoard: true`.
- Do not call `tidy_board` after moving items; lists keep their place on the canvas.

View saved version →

---
name: board-mindmap
description: Brainstorm on an Odyssey project board as a mindmap — put a central topic in the middle, branch ideas out in several directions, and turn chosen branches into tasks. Use when the user wants to "map out", "brainstorm on my board", "break this idea down", "make a mindmap of", or explore options visually before planning.
---

# Brainstorm as a mindmap

A mindmap on an Odyssey board is a **relationship**, not a special card: one `mindmap` component is
the center, and any component becomes a branch by naming its parent with `mindmapParentId`. The
board's layout engine spreads the branches, so you never compute coordinates.

## Steps

1. **Agree on the center.** Restate the topic in a few words. Pick the board (existing one via
   `list_projects`, or `create_project` after the user agrees to a name).
2. **Sketch the tree in chat first**: 3–6 first-level branches, 2–5 ideas under each, two levels
   deep at most. Ask whether to adjust before writing anything to the board.
3. **Create the center.** `add_project_component` with `type: "mindmap"` and `text` = the topic.
4. **Create the branches.** For each first-level branch, `add_project_component` with `type: "text"`
   (or `roundRect` for emphasis), `text` = the branch label, `mindmapParentId` = the center's id, and
   `mindmapDirection` spread across `right`, `left`, `down`, `up` so the map stays balanced. Add the
   second-level ideas the same way with the branch as parent and the same direction as their branch.
5. **Lay it out.** Call `tidy_board` once when the map is complete. Skip this if the board already
   had components the user arranged by hand — tell the user they can use the app's auto-arrange
   instead.
6. **Turn ideas into action (optional).** When the user picks branches to act on, make an `itemTile`
   list for them with `mindmapParentId` = that branch, then add tasks with `create_todo`
   (`projectUid` + `attachToComponentId` = the list's id). Tasks stay linked to the branch they came
   from.
7. **Report back**: the center, the branches created, and any tasks made from them.

## Guardrails

- Keep labels short (under about six words); long text belongs in a note, not a branch.
- Reuse an existing mindmap if `get_project` shows one on the same topic under `structure.mindmaps`.
- Removing branches uses `delete_project_component` and needs an explicit yes from the user.