# Meeting to Tasks

A method for turning a meeting transcript into tracked project records: decisions captured as notes, action items created as child tasks. A client engagement generates meetings, but a transcript on its own is inert — the decisions and commitments in it are not in the graph, so nothing reminds anyone to act on them. This converts the conversation into the same structures the rest of the plugin uses.

## Method: separate decisions from actions

Read the transcript and pull out two distinct kinds of content. Keep them separate — they terminate differently.

- **Decisions** — things the meeting settled. A choice made, a direction agreed, a scope change, a problem identified. These are facts about the project's history.
- **Action items** — things someone committed to do. Each has an owner (even if implicit) and an outcome. These are future work.

Discard everything else. Discussion that led nowhere, restated context, and small talk do not become records. The test for an action item is whether someone is expected to do something as a result; the test for a decision is whether the project's state changed because of it.

For each action item, capture who owns it and what "done" looks like, so it can be created as a real task rather than a vague reminder.

## Graph termination

The transcript itself is never the deliverable — the records it produces are.

- **Decisions become project notes.** Append each to the project with `project-update` using the matching lifecycle format: a settled direction or scope change as `[PROJECT:CHANGE] {what changed} — Reason: {why}`, a problem raised as `[PROJECT:ISSUE] {description} — Impact: {assessment}`, a general decision as a `[PROJECT:PHASE]` note. These land in the project's searchable history.
- **Action items become child tasks.** Create each with `work-create`, naming the owner in the task description (there is no assignee relationship — the owner lives on the task itself). Attach the task to the project via `work-relate` (`PART_OF`, passing the project `taskId`). If the transcript names who requested the action, link that person with `RAISED_BY`; link any affected entity with `AFFECTS`. The action then flows through `work-ready` and execution like any other task.

After processing a transcript, `project-get` shows new notes for the decisions and new child tasks for the action items. A transcript that produces neither was not processed — it was only read.

## Wiring

This method is invokable in any mode, not tied to a single sprint phase — meetings happen throughout a project's life. Load it via `plugin-read` whenever a transcript is pasted into a project conversation, or when the operator asks to turn meeting notes into tasks. If the meeting belongs to no existing project, create or identify the project first so the notes and tasks have a parent.

## When to Use

- A meeting transcript pasted into a project conversation.
- "Turn these notes into tasks."
- "What did we agree in that call?"
- "Capture the action items from the client meeting."