meeting-to-tasks

meeting-to-tasks

Convert a meeting into concrete, trackable work. The skill is deliberately conservative: extract → deduplicate → confirm with the user → create. Automatic creation from a transcript produces nonsense tickets far too often — human review before the first create_issue is not optional.

When to use

• The user references a meeting that produced to-dos and wants them in the tracker.
• A standup, planning, or retro transcript exists and the commitments need a paper trail.
• Follow-up from meeting-search when the user says "file tickets for this one".

Procedure

1. Pin the meeting

The skill operates on one meeting at a time. If the id is not known, fetch the short metadata list and confirm with the user:

devboy tools call get_meeting_notes '{
  "from_date": "<window start ISO>",
  "to_date":   "<window end ISO>",
  "limit": 10
}'

2. Prefer the provider's action items

get_meeting_notes returns an action_items array populated by the provider's summariser. When it is non-empty, use it — it is already filtered to imperative commitments:

devboy tools call get_meeting_notes '{
  "from_date": "<narrow window around the meeting>",
  "to_date":   "<+1 day>",
  "limit": 5
}'

Take the action_items field from the matching meeting. This is cheaper and more reliable than parsing a transcript.

3. Fallback: parse the transcript

If action_items is empty or missing, fetch the transcript and extract candidates manually. devboy tools call has no --budget flag — the format-pipeline trims the response to fit the configured tool budget internally, so just call the tool and the runtime handles truncation:

devboy tools call get_meeting_transcript '{"meeting_id": "<id>"}'

Look for:

• Imperative verb phrases attributed to a specific participant ("I'll draft the RFC", "Alice will open a ticket about X").
• "Let's…" / "We need to…" statements where someone assented.

Skip hypotheticals, questions, and vague intentions ("we should probably look into that" with no commitment attached).

4. Deduplicate ruthlessly

A 45-minute call will restate the same commitment three or four times. Before creating anything, collapse the list:

• Normalise the verb + object (e.g. "update the docs", "fix docs", "I'll update the documentation" → one item).
• Merge paraphrases of the same commitment made by the same person.
• Keep distinct items when the owner differs, even if the action is similar.

The deduplicated list is what the user will see next.

5. Confirm with the user before creating

Show the dedup'd list and wait for a go-ahead. Offer three options:

1. Create all of them as-is.
2. Create a named subset.
3. Edit titles / owners / descriptions first.

Never skip this step — automatic creation from a transcript is the single biggest source of tracker clutter this skill can cause.

6. Create one issue per item

Keep each ticket small — one action, one ticket. For each approved item:

devboy tools call create_issue '{
  "title": "Short imperative title (one line)",
  "description": "Source: meeting \"<meeting title>\" on <ISO date>.\nOwner committed: <name>.\n\nContext:\n<2–4 lines from the transcript or action_items entry>",
  "assignees": ["<handle>"],
  "labels": ["from-meeting"]
}'

Guidelines:

• Title is imperative and under ~80 chars. "Draft RFC for auth migration" not "We should probably think about the RFC".
• Description always cites the meeting title + date so the ticket is traceable back to its source.
• Assign to the committed owner when known. If unknown, leave unassigned and note the speaker in the body.

7. Optional: link issues that share a parent

If several of the new issues clearly belong to one epic the user named, link them:

devboy tools call link_issues '{
  "sourceIssueKey": "<new issue key>",
  "targetIssueKey": "<epic key>",
  "linkType": "relates_to"
}'

Use relates_to by default; only use blocks when the user stated an ordering.

8. Report back

Reply with:

• The meeting source (title + date).
• The deduplicated list of created tickets (one line each: KEY — title).
• Items that were discussed but not created (because the user dropped them), so the audit trail is complete.

Success criteria

• Zero tickets are created before the user confirms the deduplicated list.
• Every created ticket cites the source meeting in its description.
• Each ticket is one action (no multi-bullet tickets). If the extracted item has two distinct actions, it was two items and should have been split during dedup.
• The count of created tickets matches the count of approved items — no silent drops, no silent extras.

Guardrails

• Never auto-create. Even when the user says "just do it", show the list once and wait for one-key confirmation. One extra round-trip beats filing 20 bad tickets.
• Do not re-create on re-run. If the user re-runs the skill on the same meeting, use get_issues with the from-meeting label (plus the source-meeting citation in the body) to find already-created tickets before creating duplicates.
• Respect privacy. Do not paste full transcript quotes into ticket descriptions — 2–4 lines of context is enough, more is a PII leak in a system that is often more widely shared than the meeting itself.

Non-goals

• Estimating or prioritising the created tickets. The skill files them; triage is a separate step.
• Cross-meeting aggregation. One meeting → one batch of tickets.
• Updating existing tickets based on a meeting. Use update_issue directly for that — this skill only creates.