Tana

View saved version →

---
name: add-to-meeting
description: "Add something to a meeting in Tana so it is there when the meeting starts: a link, an agenda item, questions, a list of bugs, a doc, notes. Finds the right upcoming (or past) meeting and attaches the item to its agenda or meeting page. Use when the user says 'add this to my meeting with Anna', 'put these bugs on the agenda for Thursday's sync', 'attach the spec to tomorrow's design review', 'add this link to the Acme call', 'make sure we talk about X at standup', or 'add my notes to yesterday's meeting'."
---

# Add to a meeting

The user has something that belongs in a meeting: a link, a topic, a list of bugs, a doc. Put it on
the meeting so everyone sees it when the meeting opens, and tell the user where it went.

## Steps

1. **Find the meeting.** Follow step 1 of the `tana-meeting` skill. Default to the next upcoming
   occurrence: `searchItems` with `targets: [{ "target": "event", "eventStartTimeMin": "<now, local>", "eventTimeZone": "<tz>" }]`
   and the person's name, email or the meeting title in `queries`. A recurring meeting ("standup",
   "Thursday's sync") means the next occurrence unless the user says otherwise. State which meeting in
   one line: "Adding to Design review, Thu 1 Oct 10:00."

2. **Read it.** `readEvent({ eventUri })`: note `agendaUri`, `pinnedItems` and `relatedDocs`, so you
   don't add something that's already there. For a past meeting ("add my notes to yesterday's
   meeting"), also, in this order:
   1. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** Notes on a past meeting should
      point at what was shown; embed a frame with `![what it shows](cid:<cid>)`.
   2. `readScreenshotImages({ id: callUri, cids: [...] })` for the frames you will refer to (up to 10 per call).
   3. `readFullTranscript({ id: callUri })` around those frames, if the notes need the words.
   The `tana-meeting` skill has the details of each part.

3. **Gather the item.** If it lives elsewhere (bugs in an issue tracker, a web page, a file in the repo),
   collect it with the tools you have and turn it into short text with links. If it is a Tana doc,
   get its URI (search for it with `searchItems`, or take it from a pasted link).

4. **Add it the right way:**

   | What | How |
   | --- | --- |
   | An existing Tana doc | `pinItem({ operation: "pin", target: "event", targetUri: eventUri, itemUris: [docUri] })`. Applies right away; it shows on the meeting page for everyone who can see the meeting. |
   | Agenda items, questions, links, a bug list | If the agenda exists (`readItems({ ids: [agendaUri] })` returns it): `updateItems({ updates: [{ id: agendaUri, appendContent: "- Promo-code bug on mobile: <link>" }], recap })`. |
   | Same, but the meeting has no agenda yet | `createItems({ items: [{ title: "Agenda: <meeting>, <date>", content }], recap })`, then pin it with `pinItem` once the user has approved it. |
   | Longer notes or a doc to bring | `createItems` with the content, then pin it after approval. |

   Writes with `updateItems` and `createItems` land as a proposal in Tana for the user to approve;
   `pinItem` does not need approval but only works on an approved doc.

5. **Report in one or two lines** (template below), including anything that still waits for approval.

## Output

```
Added to Design review, Thu 1 Oct 10:00 <link>:
- Pinned "Checkout spec v2" to the meeting page
- Proposed 3 agenda items (the mobile promo-code bugs). Approve them in Tana to add them.
```

## Examples

- "Add this Loom link to my call with Acme": find the next event whose attendees match Acme, append
  `- Demo recording: <url>` to the agenda.
- "Put the open checkout bugs on Thursday's sync": list them (`searchItems` text target with
  `"type": "Bug"` or your issue tracker), append one line per bug with its link.
- "Attach the pricing doc to tomorrow's review": search for the doc, pin it.

## Rules

- Prefer the agenda or a pinned doc over the invite text. On a Google or Outlook event,
  `updateEvent`'s `description` only changes Tana's copy, and the next calendar sync may overwrite it.
- Keep agenda lines short: one topic per line, with the owner and a link.
- If two meetings match, name both and ask which one.
- Never write notes on a past Tana-recorded meeting before calling `readScreenShareScreenshots` for it.
  "Nothing was shared on screen" is a valid finding; skipping the call is not.

View saved version →

---
name: ask-tana
description: "Answer a quick factual question from the team's Tana meetings and docs in one or two sentences, with the source: what was decided, when something was last discussed, who owns something, which date, number or name was agreed, what was shown on screen. Use for short questions like 'what did we decide on pricing?', 'when did we last talk about the Android app?', 'who owns onboarding?', 'what deadline did we agree with Acme?', 'what did Mads show in the demo?', 'did we pick Postgres or SQLite?'. For the full history of a topic, use find-prior-art instead."
---

# Ask Tana

A small question deserves a small answer: the fact, where it came from, and a link. No essay.

## Steps

1. **Search narrowly, in one call.** Use the specific words the answer would contain.
   ```json
   { "queries": ["pricing decision", "pricing"],
     "targets": [{ "target": "text" }, { "target": "transcript" }, { "target": "event" }],
     "limit": 15 }
   ```
   (`searchItems`). If the wording is uncertain, also run
   `semanticSearchItems({ query: "what we decided about pricing", limit: 10 })`.
   - "When did we last...": search with one target only, `{ "target": "event", "eventStartTimeMax": "<now, local>", "eventTimeZone": "<tz>" }`,
     plus `"sortOptions": [{ "field": "startTime", "direction": "desc" }]` (startTime sorting needs the event target alone).
   - "Who owns...": look for a doc or task on the topic (`searchItems` text target; results carry
     `assignedTo`), and resolve profile URIs to names with `listOrgMembers`.

2. **Read only the best source.**
   - A doc: `readItems({ ids: [id], task: "<the question>" })`.
   - A meeting (one or two at most). In this order:
     1. `readEvent({ eventUri })` for `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
     2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** A decision or number is often on
        a slide or sheet, not in the words. Add `startSec` / `endSec` once you know where to look.
     3. `readScreenshotImages({ id: callUri, cids: [...] })` only when the answer is a number, date, name
        or choice shown on a frame: read it off the pixels.
     4. `readFullTranscript({ id: callUri })` to find the passage (narrow with `startSec` / `endSec`).
     5. `readItems` on the summary or attached docs with a `task`, if they hold the answer.
     The `tana-meeting` skill has the details of each part.
   - A pasted Tana link: read exactly that item (the `tana-meeting` skill shows how).

3. **Check it is still true.** If a later meeting or doc changed the answer, the latest one wins.
   A quick `searchItems` sorted by recency on the same keywords is enough.

4. **Answer** with the template. Get the link with `getShareLink({ ids: [...] })`.

## Output

```
**$49 per seat per month, annual only.** Decided in Pricing sync, Tue 22 Sep (at 18:40), proposed
by Hilde and agreed by Mads; the pricing table was on screen. <link>
```

When the answer changed over time:
```
**Postgres.** Decided in Architecture review, 14 Sep (at 05:10) <link>.
(An earlier sync on 2 Sep had leaned towards SQLite.)
```

## Rules

- One or two sentences. Bold the answer.
- Always name the source: meeting or doc, date, and who, plus mm:ss for meetings.
- Never answer from a Tana-recorded meeting before calling `readScreenShareScreenshots` for it.
  "Nothing was shared on screen" is a valid finding; skipping the call is not.
- Say "decided" only if it was decided. Otherwise: "discussed, not decided".
- Not found? "I couldn't find that in Tana." Then one line on what you searched.
- If the user wants more, offer the `find-prior-art` history in one line.

View saved version →

---
name: create-from-meeting
description: "Turn a Tana meeting into something new: a 'here's what we agreed' recap for a client, a brief, a slides outline, a storyboard, a Slack or email recap, a proposal, a follow-up email, a video script, an FAQ, a training guide, anything. Built from what was said (the transcript) and what was shown (screen-share screenshots of the sketches, designs, slides and spreadsheets people looked at). Use when the user says 'write up the design review for the client', 'recap yesterday's call for Slack', 'turn the workshop into slides', 'draft a proposal from my call with Acme', 'storyboard the demo', 'send them what we agreed', or 'make something from this meeting'."
---

# Create from a meeting

Any meeting can become a deliverable. Take a design consultant who walked a customer through
sketches: the screenshots are the sketches, and the transcript is the customer saying "move this
up, make that bigger, drop the sidebar". Put the two together and you get "here's what we agreed",
sketch by sketch, ready to send. **The screenshots are the source for what was reviewed. The
transcript is the source for what was said about it.**

## Steps

1. **Read the meeting.** Locate it (see the `tana-meeting` skill), then, in this order:
   1. `readEvent({ eventUri })` for `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
   2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** The frames are the sketches,
      designs and slides the deliverable is about.
   3. `readScreenshotImages({ id: callUri, cids: [...] })` for the frames that carry the substance
      (up to 10 cids per call).
   4. `readFullTranscript({ id: callUri })`, reading around the frames that mattered.
   5. `readItems` on the summary and attached docs, with a `task`.
   The `tana-meeting` skill has the details of each part.

2. **Pick the shape and the reader.** If the user named a format, use it. If not, ask one short
   question ("Slack recap, client email, or slides?"). A customer-facing piece drops internal
   chatter, prices not yet agreed, and anything said about the customer.

3. **Walk the screen, frame by frame.** For each frame that was discussed:
   - look at the pixels (step 1.3) for sketches, designs, slides and numbers
   - read the transcript for that frame's window (`capturedAtSec` to `visibleUntilSec`)
   - write what was agreed about that frame, in plain words, and who asked for it
   Frames nobody talked about are usually scrolling; leave them out.

4. **Draft it in the chat first.** Use the template for the format (below). Keep the sketch or slide
   next to the change it drives. Mark anything that was discussed but not decided.

5. **Offer to save it in Tana**, in one line. Two ways:
   - a doc: `createItems({ items: [{ title, content }], recap })`. Embed screenshots in `content`
     with `![what it shows](cid:<cid>)`, copying the full 64-character cid from
     `readScreenShareScreenshots`.
   - a visual artifact: `createArtifact({ artifactType, title, data, recap })`, where `artifactType`
     is `"slides"`, `"storyboard"` or `"customer-journey"`. First call
     `readSkill({ title: "Create storyboard artifact" })` (or `slides` / `customer journey`) to get that
     type's `data` schema. In a storyboard, put the real screen-share frames in the scenes'
     `screenshotIds`: what was actually on screen beats a generated illustration.
   Either one lands as a proposal in Tana for the user to approve. Once approved, offer to pin it to
   the meeting page: `pinItem({ target: "event", targetUri: eventUri, itemUris: [docUri] })`.

## Templates

**Here's what we agreed (design or product review)**
```
<Project>: what we agreed, <date>

1. Checkout page (sketch 1)
   ![Checkout sketch](cid:...)
   - Move the promo-code field above the total (Lena)
   - CTA becomes green, full width (agreed by all)
2. Order confirmation (sketch 2)
   - Keep as is
Still open: delivery-date picker, you'll send two options by Friday.
Next step: revised sketches Thursday 10:00.
```

**Slack recap**
```
*<Meeting>, <date>* (<link>)
Decided: ...
Shown: <the dashboard / demo / sketch>, key takeaway: ...
Owners: @Anna: ..., @Mads: ...
Open: ...
```

**Slides outline:** one slide per frame or topic: headline (the decision), the screenshot, two
supporting bullets from the transcript, speaker note with the quote.

Other shapes follow the same pattern: brief, proposal, follow-up email, video script, FAQ,
onboarding guide, bug report, customer-journey map, press note. Pick the frames that matter, pair
each with what was said, and write for the reader.

## Rules

- Never invent an agreement. "We discussed X" is not "we agreed X".
- Attribute requests and decisions to the person who made them.
- Numbers, names and on-screen text come from the screenshot, checked in the pixels.
- Never write before calling `readScreenShareScreenshots` for each Tana-recorded meeting you use.
  "Nothing was shared on screen" is a valid finding (then build from the transcript and attached
  docs); skipping the call is not.
- Keep it as long as the reader needs, not as long as the meeting was.

View saved version →

---
name: do-my-tasks
description: "Work through the user's open tasks in Tana: list what is assigned to them, including action items from their recent meetings, do the ones an agent can do (draft the doc, do the research, write the code, prepare the reply), and propose the results and completions back into Tana. Leaves the human-only ones with a one-line reason. Use when the user says 'look at my tasks and do the ones you can', 'clear my backlog', 'what's on my plate, and can you handle any of it?', 'do my follow-ups from yesterday's meetings', or 'work through my Tana tasks'."
---

# Do my tasks

The user has a list of things they said they'd do. Many are agent work: a draft, a summary, some
research, a code change, a reply. Find them, do the ones you can, put the results back into Tana for
the user to approve, and hand back a short list of what only they can do.

## Steps

1. **Who is "me".** `getCurrentUser` gives the user's profile URI and name.

2. **List open tasks.**
   ```json
   { "queries": ["*"],
     "targets": [{ "target": "text", "state": ["Inbox", "In Progress"], "assignedTo": ["tana:user-profile:..."] }],
     "limit": 50 }
   ```
   (`searchItems`). Skip `Later` unless the user asks for it.

3. **Add action items from recent meetings.** `listEvents` for the last 7 days (or the range the user
   names). For each one, `readEvent` gives `participants` and `summaryUri`; for meetings the user
   joined, read the summary with `readItems({ ids: [summaryUri], task: "action items and commitments for <name>" })`. Where the summary
   is thin, scan the transcript (`readFullTranscript`) for "I'll ...", "can you ..., <name>". Drop anything
   already covered by a task from step 2.

4. **Understand each task.** `readItems({ ids: [...], task: "what exactly is asked, by whom, by when, linked docs" })`.
   To find the meeting a task came from, `getItemInfo({ ids: [taskUri] })`: when `createdIn` or `ownerUri`
   is a `tana:event:` URI, read that meeting, in this order:
   1. `readEvent({ eventUri })` for `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
   2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** The frames show what the task
      actually refers to: the thing to fix, the doc to change, the numbers to check. The task title alone won't tell you.
   3. `readScreenshotImages({ id: callUri, cids: [...] })` for the frames around the moment the task came up
      (up to 10 cids per call).
   4. `readFullTranscript({ id: callUri })`, reading around those frames.
   5. `readItems` on the summary and attached docs, with a `task`.
   The `tana-meeting` skill has the details of each part.

5. **Triage and show it** before doing anything (skip the wait if the user said "just go"):

   | Can do now | Needs you | Unclear |
   | --- | --- | --- |
   | drafts, replies, research, summaries, specs, code (in a coding agent with the repo open), breaking a task into sub-tasks | a decision, a conversation, an approval, a payment, being somewhere, access you don't have | missing context: ask one question |

6. **Do the work**, one task at a time. Cite the meeting or doc each result is based on.

7. **Put the results back in Tana.** Pass a `recap` on every write:
   - the result as a new doc: `createItems({ items: [{ title, content }], recap })`, or appended to the
     task itself: `updateItems({ updates: [{ id: taskUri, appendContent: "## Draft\n..." }], recap })`
   - a meeting action item with no task yet: `createItems({ items: [{ title, state: "In Progress", assignedTo: ["<me>"] }], recap })`
   - completion, only when the task is fully done: `updateItems({ updates: [{ id: taskUri, state: "Completed" }], recap })`
   Everything lands as a proposal in Tana for the user to approve.

8. **Report** (template below).

## Output

```
Did 3 of 7. Everything is proposed in Tana, waiting for your approval.

Done
- "Write Acme follow-up email": draft added to the task, based on the 29 Sep call (the pricing
  table they saw at 18:40). Proposed Completed.
- "Research SSO providers": comparison doc proposed <link>
- "Fix promo-code crash": fix on branch fix/promo-total; the error came from the standup screenshot at 07:45

Needs you
- "Decide Q4 hiring plan": your decision
- "Call Lena about the contract": a conversation
- "Approve Figma budget": needs your sign-off

Unclear
- "Update the deck": which deck? The 22 Sep review showed two.
```

## Rules

- Never mark a task Completed that you only started. Append the partial work and leave the state.
- Never send anything on the user's behalf (email, Slack, invites). Draft it; they send it.
- In a chat app with no code access, turn a code task into a short implementation plan instead.
- Never start a task that came from a Tana-recorded meeting before calling `readScreenShareScreenshots`
  for that meeting. "Nothing was shared on screen" is a valid finding; skipping the call is not.
- For meeting action items, work from the meeting's summary, attached docs, transcript and
  screenshots. Don't invent owners: only take what was clearly given to the user.

View saved version →

---
name: find-prior-art
description: "Search the team's Tana meetings and docs for earlier discussion of a topic: past feedback, bug reports, decisions, objections, customer requests, experiments that were tried. Reads the best hits, including the exact transcript passages and screenshots where the topic came up, and reports what was said, when and by whom, with links. Use when the user asks 'has anyone discussed this before?', 'did we try this already?', 'any feedback on X?', 'what have customers said about Y?', 'have we seen this bug before?', 'what's the history of Z?', or is mid-work and wonders whether the team has been here before. For one quick fact (a decision, a date, an owner), use ask-tana instead."
---

# Find prior art

Someone halfway through a piece of work wants to know whether the team has been here before.
The answer usually sits in a meeting: a customer complaining on a call, a bug someone screen-shared
in standup, a design review that already rejected the idea. This skill searches meetings and docs,
reads the passages where the topic came up, and reports the history with links.

## Steps

1. **Frame the search.** Write 2–4 keyword variants (product names, feature names, error strings,
   customer names, the team's slang) and one plain-language description of the topic.

2. **Search wide, in parallel.**
   - Keywords across docs, transcripts and meetings, batched in one call:
     ```json
     { "queries": ["promo code", "discount field", "coupon"],
       "targets": [{ "target": "text" }, { "target": "transcript" }, { "target": "event" }],
       "limit": 30 }
     ```
     (`searchItems`)
   - Meaning, for what nobody named the same way: `semanticSearchItems({ query: "customers confused about where to enter a discount", limit: 20 })`.
   - If the workspace files things like bugs or feedback as typed docs, narrow with the text target's
     `type` (`"type": ["Bug", "Feedback"]`); `getTypes` lists the names. Skip this if it isn't obvious.

3. **Pick the best 5–8 hits.** Prefer exact matches, decisions over chatter, customers over guesses,
   and recent over old, but keep the oldest relevant hit: it shows how long this has been around.

4. **Read them.**
   - Docs: `readItems({ ids: [...], task: "what was said about <topic>: decisions, feedback, who, when" })`.
   - Meetings (hits of kind event, transcript or call share one id: `tana:event:<id>`, `tana:transcript:<id>`,
     `tana:call:<id>`). For every meeting hit you read, in this order:
     1. `readEvent({ eventUri })` for the date, people, `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
     2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** A decision or number is often on
        a slide or sheet, not in the words. Add `startSec` / `endSec` to focus on the passage.
     3. `readScreenshotImages({ id: callUri, cids: [...] })` for the frames that show the bug, design or
        data being discussed (up to 10 cids per call).
     4. `readFullTranscript({ id: callUri })`, reading around the frames and the passage that matched
        (narrow with `startSec` / `endSec`).
     5. `readItems` on the summary and attached docs with a `task`, if the passage needs them.
     The `tana-meeting` skill has the details of each part.

5. **Get links.** `getShareLink({ ids: [...] })` for every meeting and doc you cite.

6. **Report** (template below), newest first.

## Output

```
Yes, this has come up 4 times since March.

- Tue 29 Sep · Design review (Anna, Mads) · <link>
  At 12:10 Anna showed the checkout sketch with the promo field under the total; Mads: "people
  miss it down there." Decided: move it above the total.
- 14 Aug · Acme onboarding call · <link>
  Customer (Lena, Acme) couldn't find where to add their code; screen showed the cart page at 31:40.
- 2 Jul · Bug: "Promo code ignored on mobile" (doc, Completed) · <link>
- 11 Mar · Pricing sync: tried auto-applied codes, dropped (support load). · <link>

What this means now: moving the field is already decided; auto-applying codes was tried and
dropped in March.
```

## Rules

- Quote briefly and exactly; give the date, the speaker and the mm:ss.
- Never report on a meeting hit before calling `readScreenShareScreenshots` for it. "Nothing was shared
  on screen" is a valid finding; skipping the call is not. (Search results you don't read need no call.)
- Say what was on screen when it matters ("the error on screen was...").
- Separate what was decided from what was only said.
- Nothing found? Say so, and list what you searched for, so the user can refine.
- Don't read every hit in full. Read the passages that answer the question.

View saved version →

---
name: implement-from-meeting
description: "Turn what was discussed in a Tana meeting into working code. Builds the spec from the transcript and the screen-share screenshots (the bug, UI, sketch or diagram shown on screen is often the real spec), lists decisions and constraints, confirms a short plan, then implements it in the codebase. Works for a bug fix, a feature or a whole new project. Use in coding agents (Claude Code, Codex, Cursor) when the user says 'implement what we talked about in the design sync', 'fix the bug we looked at in standup', 'build what we sketched with Anna', 'start the project we scoped on Monday', or pastes a Tana meeting link and asks for code."
---

# Implement from a meeting

Meetings are where specs get made, and most of the spec was on screen: the error someone shared,
the Figma frame everyone pointed at, the whiteboard sketch, the table of edge cases. The transcript
says what people decided about it. This skill turns both into a confirmed plan and then into code.

## Steps

1. **Read the meeting.** Locate it (see the `tana-meeting` skill), then, in this order:
   1. `readEvent({ eventUri })` for `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
   2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** The bug, UI or sketch on screen
      is often the real spec, and nobody reads it out in full.
   3. `readScreenshotImages({ id: callUri, cids: [...] })` for the frames that carry the substance
      (up to 10 cids per call).
   4. `readFullTranscript({ id: callUri })`, reading around the frames that mattered.
   5. `readItems` on the summary and attached docs, with a `task`.
   The `tana-meeting` skill has the details of each part.

2. **Mine the screenshots for the spec.** For every frame that shows something to build or fix,
   look at the pixels (step 1.3). Pull out exactly:
   - error messages, stack traces, log lines, URLs and routes
   - UI copy, labels, component and screen names, layout, spacing, colours, states
   - data: column names, example values, numbers, edge cases in a table
   - sketches and diagrams: boxes, arrows, what moves where
   Then read the transcript for that frame's window (`capturedAtSec` to `visibleUntilSec`) to learn
   what was decided about it. The frame gives the exact thing; the talk gives the intent.

3. **Read what the meeting pointed to.** Docs in `relatedDocs` or `pinnedItems`, and any doc, ticket
   or spec named out loud: `searchItems({ queries: ["checkout spec"] })`, then `readItems`.

4. **Write the spec in chat** (template below). Separate decided from merely discussed.

5. **Map it to the codebase.** Strings seen on screen are exact search keys: grep for the error text,
   the UI label, the route. Find the component, handler or module each item touches.

6. **Confirm the plan in a few lines** and wait for an OK: what you will change, where, what you will
   not touch, and any open question that blocks you. Skip the wait only if the user said "just do it".

7. **Implement.** Follow the repo's conventions and instructions files. For a bug, reproduce it first
   with the error from the screenshot; write the failing test, then fix. For UI, compare your result
   against the frame. Run the project's tests and checks.

8. **Report back** (template below). Offer, in one line, to record the result in Tana, for example a
   short "implemented" note appended to the meeting summary:
   `updateItems({ updates: [{ id: summaryUri, appendContent }], recap })`.
   That lands as a proposal in Tana for the user to approve.

## Spec template

```
Meeting: <title>, <date> · <link from getShareLink>
Goal: <one sentence>

What was shown
- [07:45] Sentry error "TypeError: total is undefined" on /checkout (frame: Sentry issue page)
- [12:10] Figma: promo-code field moved above the total, CTA green (frame: Checkout v2)

Decided
- Promo field goes above the total (Anna, 12:30)
- Fix the undefined total before the redesign ships (Mads, 09:05)

Constraints / out of scope
- No backend changes this round (Hilde, 15:20)
- "Maybe later": saved payment methods (not in this change)

Open questions
- Should the CTA colour follow the theme token or be hard-coded green?

Done when
- /checkout with an empty cart shows 0, no error; promo field above total; tests green
```

## Report template

```
Implemented from <meeting>, <date>:
- <change> (<file>) covers "<decision>"
- <change> (<file>) fixes the error shown at 07:45
Not done: <item> (<why>)
Checks: <command> passed
```

## Kinds of work

- **Bug:** the screenshot usually holds the exact error and the screen it happened on. Start there.
- **Feature:** the design frame is the spec; the transcript gives priorities and what was cut.
- **New project:** scaffold only what was agreed. List the rest as follow-ups, don't build it.

## Rules

- Exact strings come from the screenshot, not from someone paraphrasing it out loud.
- Build what was decided. Ideas floated with "maybe", "later" or "what if" go under out of scope.
- When the meeting changed its mind, the later decision wins. Mention the reversal in the spec.
- If the screenshots contradict the transcript, stop and ask; don't guess.
- Never build before calling `readScreenShareScreenshots` for each Tana-recorded meeting you use.
  "Nothing was shared on screen" is a valid finding (then lean on the transcript and linked docs);
  skipping the call is not.

View saved version →

---
name: prep-meeting
description: "Prepare the user for an upcoming meeting: who is coming, what the invite says, what happened the last times with these people or on this topic (including what was shown on screen), open items and decisions, and 3–5 sharp questions to ask. Offers to attach the prep to the meeting in Tana. Use when the user says 'prep me for my 2 pm', 'what do I need to know before the Acme call?', 'brief me for tomorrow's 1:1 with Mads', 'get me ready for the design review', 'what's my next meeting about?', or 'prep my meetings today'."
---

# Prep a meeting

Walk in knowing what happened last time, what is still open, and what to ask. The best prep comes
from the last meetings with the same people: what they said, and what everyone looked at on screen
(the demo they saw, the proposal on the table, the numbers that worried them).

## Steps

1. **Find the meeting.**
   - "My 2 pm", "tomorrow's 1:1": `listEvents({ startDate, endDate, timezone })` for that day, then match by time or title.
   - "My next meeting": `searchItems` with `targets: [{ "target": "event", "eventStartTimeMin": "<now, local>", "eventTimeZone": "<tz>" }]` and query `"*"`.
   - A pasted link: read exactly that meeting (the `tana-meeting` skill shows how).
   - "Prep my meetings today": list the day and prep each one, shortest first.

2. **Read the upcoming event.** `readEvent({ eventUri })`: title, time, `description` (the invite often
   holds the agenda or a named doc), `attendees` with email domains (internal or external?), `organizer`,
   `pinnedItems`, `relatedDocs`. Read the agenda with `readItems({ ids: [agendaUri] })`; it may not exist.

3. **Find the previous meetings.**
   - Recurring meeting: follow `previousInstance` back one or two occurrences.
   - Otherwise search past events with the same people or topic, most recent first:
     ```json
     { "queries": ["acme.com", "Lena Berg", "onboarding"],
       "targets": [{ "target": "event", "eventStartTimeMax": "<now, local>", "eventTimeZone": "<tz>" }] }
     ```
   Take the 2–3 most relevant.

4. **Read each previous meeting fully.** For every past meeting you use, in this order:
   1. `readEvent({ eventUri })` for `callUri`, `summaryUri`, `relatedDocs`, `pinnedItems`.
   2. `readScreenShareScreenshots({ id: callUri })`. **Not optional.** The frames are the only record of
      what people were looking at: the roadmap, the sketch, the numbers, the bug. Note what was shown
      and when ("they saw the Q3 roadmap at 14:20 and pushed back on the October date").
   3. `readScreenshotImages({ id: callUri, cids: [...] })` for anything you will refer to: a price, a
      date, a design, a chart. Up to 10 cids per call.
   4. `readFullTranscript({ id: callUri })`, reading the lines around each frame that mattered.
   5. `readItems` on the summary and attached docs, with a `task`.
   The `tana-meeting` skill has the details of each part.

5. **Find what's still open.**
   - Tasks on the topic: `searchItems` with `targets: [{ "target": "text", "state": ["Inbox", "In Progress"] }]`
     and the topic or company as `queries`.
   - Related decisions and docs: `semanticSearchItems({ query: "<topic of the meeting>", limit: 10 })`, then
     `readItems` with a `task` for the few that matter.

6. **Write the prep** (template below). Keep it to one screen.

7. **Offer to attach it**, in one line. If the user agrees:
   - create the prep doc: `createItems({ items: [{ title: "Prep: <meeting>, <date>", content }], recap })`.
     This lands as a proposal in Tana for the user to approve.
   - once they have approved it, pin it to the meeting page so it's there when the meeting starts:
     `pinItem({ target: "event", targetUri: eventUri, itemUris: [docUri] })`. Pinning only works on an
     approved doc; if it is still pending, say so and pin after approval.

## Output

```
**Acme onboarding check-in · Thu 1 Oct, 14:00–14:30** · <link>
With: Lena Berg, Jonas Ek (Acme); Mads (us)
Why: follow-up on the pilot rollout (from the invite)

Last time (Tue 22 Sep) <link>
- They saw the admin dashboard demo; liked it, but Lena asked twice about SSO (at 12:40)
- On screen at 18:05: pilot timeline with go-live 15 Oct. Jonas: "tight but OK"
- We promised a security questionnaire by Friday

Open
- Security questionnaire: task assigned to Mads, In Progress <link>
- SSO: not on the roadmap yet

Ask
1. Is 15 Oct still the go-live date on their side?
2. Is SSO a blocker for the pilot, or for the full rollout?
3. Who signs off the security review at Acme?
```

## Rules

- Prep is for the user, not the attendees. Be frank about risks.
- Every claim about last time carries a date and, for meetings, a mm:ss.
- Never write the prep before calling `readScreenShareScreenshots` for each Tana-recorded past meeting.
  "Nothing was shared on screen" is a valid finding; skipping the call is not.
- If there is no earlier meeting with these people, say so and prep from the invite and docs.
- Questions must come from real open items, not generic ones.

View saved version →

---
name: schedule-meeting
description: "Set up a meeting in Tana and the user's calendar: check the user's calendar for a free slot, then create the event with the right people, time and an agenda. Use when the user says 'set up a meeting with Anna and Mads on Thursday about pricing', 'book 30 minutes with the Acme team next week', 'schedule a follow-up to today's design review', 'find time for a 1:1 with Hilde', or 'put a call with lena@acme.com on my calendar'."
---

# Schedule a meeting

Turn "set up a meeting with X and Y about Z" into a real calendar event with the right people, a
sensible time and an agenda, so the meeting starts with context instead of "so, why are we here?".

## Steps

1. **Parse the ask:** who, when (a day or a window), how long (default 30 minutes), what about.

2. **Resolve the people.**
   - Teammates: `listOrgMembers` gives user-profile URIs. They go in `participants` as `{ "uri": "tana:user-profile:..." }`
     and get access to the meeting's notes in Tana. Never list the user themselves; they are the organizer.
   - External people: only email addresses the user gave you go in `attendeeEmails`. Never guess or
     complete an address. If the user only gave a name, look for it in a past meeting's `attendees`
     (`readEvent`), and confirm the address with the user before using it.

3. **Check the user's calendar.**
   - `listCalendars`: the calendar with `isDefaultWriteTarget: true` is where the event goes. If none is
     marked, or `connectionAccess` is `"read-only"`, the event stays in Tana and no invites go out. Tell
     the user before you create it.
   - `listEvents({ startDate, endDate, timezone })` over the window to find free slots. You can see only
     the user's own calendar, not other people's availability; say so when you propose a time.

4. **Build the agenda.** From the topic, in 2–5 lines. For a follow-up ("follow-up to today's design
   review"), read that meeting with the `tana-meeting` skill, including its screen-share screenshots,
   and build the agenda from what is still open and what was shown ("revisit the checkout sketch from
   12:10"). Link the earlier meeting with `getShareLink`.

5. **Confirm in 2–3 lines** and wait for an OK: title, day and time with timezone, people, agenda.

6. **Create it:**
   ```json
   { "title": "Pricing: annual plans",
     "startTime": "2026-10-01T14:00:00",
     "endTime": "2026-10-01T14:30:00",
     "timezone": "Europe/Oslo",
     "description": "Agenda\n- Annual discount: 15% or 20%?\n- Who owns the pricing page change\nContext: Pricing sync 22 Sep <link>",
     "participants": [{ "uri": "tana:user-profile:..." }],
     "attendeeEmails": ["lena@acme.com"],
     "recap": "A 30-minute pricing meeting with Anna and Mads on Thursday, agenda included." }
   ```
   (`createEvent`). This lands as a proposal in Tana for the user to approve. Approving it creates the
   event and may send real calendar invitations.

7. **Report** in one or two lines, and pass on anything the result says about a missing calendar
   connection or default calendar, including the step it points to.

## Output

```
Proposed in Tana: "Pricing: annual plans", Thu 1 Oct 14:00–14:30 (Oslo) with Anna, Mads and
lena@acme.com, agenda included. Approve it in Tana to add it to your Google Calendar and send invites.
```

## Rules

- Times are local wall times without a UTC offset (`2026-10-01T14:00:00`) plus `timezone` (an IANA
  name like `Europe/Oslo`). Never compute offsets or Unix timestamps. If the tool asks a
  daylight-saving question, ask the user and wait.
- Always set `endTime`; otherwise the external copy defaults to 30 minutes.
- No all-day events: this tool only makes timed ones. Ask for a time.
- No start time given and no window to search? Ask; don't guess.
- To move or change a meeting that already exists, use `updateEvent` with `eventUri`, `startTime`,
  `endTime` and `inputTimezone`; to add external invitees, use `addAttendeeEmails`.

View saved version →

---
name: tana-meeting
description: "Find and fully read a Tana meeting: the transcript, every screen-share screenshot, attendees, attached docs and outcomes. Use whenever the user mentions a meeting, call, sync, standup, 1:1, demo, interview, workshop or customer call ('yesterday's design sync', 'my call with Acme', 'the meeting on Tuesday', 'what did we look at in the review?'), pastes a Tana link (home.tana.inc, meet.tana.inc or a tana: URI), or another Tana skill says to locate and read a meeting. Also the reference for how writes to Tana work: every change becomes a proposal the user approves in Tana."
---

# Read a Tana meeting

A Tana meeting is more than a transcript. Tana joins the call, transcribes it, and captures
**screenshots of whatever was shared on screen** (never camera video, never faces). Those
screenshots are the only record of what people were actually looking at: the bug, the Figma
sketch, the spreadsheet, the slide. People say "this", "here", "move that up", and the
screenshot is what "this" was. **Read the screenshots every time, before you answer.**

## What a meeting holds

| Part | Tool | Use it for |
| --- | --- | --- |
| Event | `readEvent` | title, time, `attendees` (invited), `participants` (joined), `organizer`, `description` (the invite text, often the agenda), and the URIs below |
| Screen-share screenshots | `readScreenShareScreenshots`, `readScreenshotImages` | what was on screen, and when: designs, bugs, numbers, slides, code |
| Transcript | `readFullTranscript` | who said what, when: decisions, commitments, objections |
| Summary | `readItems` on `summaryUri` | Tana's wrap-up: decisions and action items |
| Attached docs | `readItems` on `relatedDocs` and `pinnedItems` | docs Tana drafted during the meeting from its live suggestions (recaps, storyboards, slides, notes), and docs people pinned |
| Agenda | `readItems` on `agendaUri` | the shared agenda, if someone wrote one |

## Step 1: find the meeting

**A pasted link wins. Read exactly that item, don't search.**
- `https://meet.tana.inc/<code>` or a bare code like `xhq-dckf-dxx`: pass it verbatim, `readEvent({ eventUri: "xhq-dckf-dxx" })`.
- `https://home.tana.inc/...`: find the `tana%3Aevent%3A<id>` segment, URL-decode it to `tana:event:<id>`, then `readEvent`. Other kinds in the URL: `tana:text:` goes to `readItems`, `tana:call:` or `tana:transcript:` to `readFullTranscript`, anything else to `getItemInfo({ ids: [...] })`.
- A raw `tana:...` URI: same routing.

**By date:** `listEvents({ startDate: "2026-09-29", endDate: "2026-09-29", timezone: "Europe/Oslo" })`.
Resolve "yesterday" or "last Tuesday" yourself. Use the user's IANA timezone (ask once if you don't know it).
Add `query` to filter by title. Each row's time field says whether it already happened.

**By title, topic or person:**
```json
{ "queries": ["design sync"],
  "targets": [{ "target": "event", "eventStartTimeMax": "2026-09-30T18:00:00", "eventTimeZone": "Europe/Oslo" }],
  "sortOptions": [{ "field": "startTime", "direction": "desc" }] }
```
That is `searchItems`. Event `queries` also match attendee names and emails ("acme.com", "Anna").
For teammates you can filter with `hasParticipantUris` (user-profile URIs from `listOrgMembers`).
- "Last" or "previous" meeting: only `eventStartTimeMax` = now, query `"*"`, most recent comes first.
- "Next" or "upcoming": only `eventStartTimeMin` = now, query `"*"`, soonest comes first.
- Start-time bounds are local wall times with no UTC offset, plus `eventTimeZone`.

**Recurring meetings:** `readEvent` returns `previousInstance` and `nextInstance`; `listEvents({ recurrenceId, ... })` lists the series.

**Several matches?** Pick the likeliest by date and people, and say which in one line
("Using Design sync, Tue 29 Sep, with Mads and Hilde."). Ask only when it is genuinely a coin flip.

## Step 2: read the event

`readEvent({ eventUri })`. Keep `callUri`, `summaryUri`, `agendaUri`, `relatedDocs`, `pinnedItems`.
Companion URIs (`callUri`, `transcriptUri`, `agendaUri`) come back even when that document does not
exist. A meeting with no `participants` and no transcript never happened as a Tana call.

## Step 3: read the screen-share screenshots (always)

1. `readScreenShareScreenshots({ id: callUri })`. Pass the **call** URI (`tana:call:<same id as the event>`), not the event URI.
   You get every unique frame in order: `cid`, `capturedAtSec`, `visibleUntilSec`, `title`, `summary`, `details`.
2. Read every `details`. Build a timeline of what was on screen:
   `03:10–07:45 Figma: checkout page v2 · 07:45–12:00 Sentry: "TypeError: total is undefined"`.
3. Look at the pixels with `readScreenshotImages({ id: callUri, cids: [...] })` (up to 10 cids per call)
   whenever the image is the substance: a sketch or mockup, a UI to build or fix, an error or stack
   trace, numbers in a chart or sheet, a diagram, anything the user will act on.
4. No frames? Say "nothing was shared on screen in this meeting". That is a fact, not a failure.

`readEvent`'s own `screenshots` field is only a few wrap-up picks. Always use the full list.

## Step 4: read the transcript against the screen

`readFullTranscript({ id: callUri })` (an event URI works too). Lines look like `[2646s] Anna: text`.
For long meetings, read windows with `startSec` / `endSec`.

**Pair the two.** A frame is on screen from `capturedAtSec` until `visibleUntilSec`; the transcript
lines in that window are what people said about it. Resolve every "this", "that button", "the red
one", "move it here" against the frame that was visible at that second. Cite moments as mm:ss
(2646s is 44:06).

## Step 5: read outcomes and attached docs

- `readItems({ ids: [summaryUri, ...relatedDocs, ...pinnedItems], task: "<what you need from them>" })`.
- `agendaUri`: `readItems` too; it may not exist.

## Linking back

`getShareLink({ ids: [eventUri, docUri] })` returns https:// links that open in Tana for members of the
workspace. Use them whenever you cite a meeting or doc outside Tana (code comments, Slack, chat apps).

## Writing to Tana: every write is a proposal

Every write tool (`createItems`, `updateItems`, `createEvent`, `updateEvent`, `createArtifact`,
`deleteItems`, ...) creates a **proposal**. The user reviews and approves it in Tana; nothing changes until
they do. That is the contract: you never change Tana silently.

- Always pass `recap`: 1–2 sentences to the user about what you propose and why. It opens the proposal in Tana.
- Leave `autoApprove` unset and never call `approveProposals` on your own. Do either only when the user
  explicitly tells you, in this conversation, to apply the change without review.
- After a write, say in one line: "Proposed in Tana: <what>. Open it in Tana to approve."
  `listProposals({ sessionUri })` shows what is pending (the write result returns `sessionUri`).
- One exception: `pinItem` applies immediately (it only adds a doc to a meeting page). Say what you pin.

## Rules

- Screenshots before answers. Never describe what was reviewed, designed or debugged from the transcript alone.
- Quote, don't invent. If what was said and what was shown disagree, say so.
- `attendees` were invited; `participants` actually joined.
- Answer the question. Don't paste the transcript back.