meeting-to-issue

name	meeting-to-issue
description	Turn a meeting transcript or summary into well-structured GitHub Issues with acceptance criteria, labels, milestone, and assignees. Trigger when given a Teams transcript, meeting notes, or product-discussion summary that contains action items.
license	MIT
metadata	{"author":"Zava Engineering","source":"Zava platform team — derived from runbook for sprint-prep meetings"}

meeting-to-issue

Take a meeting input (transcript, notes, summary) and emit one or more ready-to-merge GitHub Issues that the team can pick up without further clarification.

When to use this

• Sprint planning, design review, incident retrospective, or any cross-team meeting where action items emerged.
• The input is conversational (transcript or notes), not yet structured.
• You want the team to pick up tickets next morning without "what did we mean by this?" Slack threads.

When NOT to use this

• The input is already a structured ticket — just create the issue directly.
• The meeting was exploratory with no concrete asks — write a discussion summary instead.

Inputs

• Required: raw meeting input (transcript paste, notes file, or summary).
• Optional: target repository (default: current repo from git remote), milestone, team prefix for labels.

Output

For each action item identified, one GitHub Issue with this shape:

## Context
<2–3 sentences linking back to the meeting + why this matters>

## What we want
<concrete deliverable, observable from outside>

## Acceptance criteria
- [ ] <testable condition 1>
- [ ] <testable condition 2>
- [ ] <testable condition 3>

## Out of scope
- <what we explicitly are NOT doing>

## Notes from the discussion
> <verbatim quote(s) from the input that motivated this ticket>

---
_Generated by `meeting-to-issue` from <meeting name / date>._

Plus: labels (e.g. team/<team>, type/feature or type/bug or type/chore), milestone if known, optional assignee suggestion based on who took the action in the meeting.

Process

1. Identify action items. Look for: explicit "action: X", "we need to Y", "let's", future-tense commitments, decisions that imply work. Ignore opinions, status updates, and questions that were resolved in the meeting itself.
2. For each action item, draft a single ticket. Do not bundle two unrelated actions into one ticket — they will get blocked on each other.
3. Pull verbatim quotes from the input into the "Notes from the discussion" section. This is the audit trail; it must survive future paraphrasing.
4. Surface ambiguity as a ## Open questions section at the bottom of the ticket. Do not invent acceptance criteria you cannot defend.
5. Suggest labels from the repo's existing label set (read .github/labels.yml or query the repo). Do not invent new labels.

Hard rules

• Verbatim quotes only in "Notes from the discussion." No paraphrase, no summary, no smoothing. The ticket reader must be able to re-derive your interpretation.
• One action item = one ticket. Bundling is the #1 reason these tickets get stuck.
• Never silently drop ambiguity. If you're unsure what "X" means, write it as an open question and let the human decide.

Example invocation

> Use the meeting-to-issue skill on docs/2025-05-12-sprint-planning-notes.md.
> Target repo: DevExpGbb/zava-storefront. Milestone: Sprint-23.

See also

• panel-review skill — for reviewing PRs that close these issues.
• incident-to-pr skill — sibling skill for the postmortem-to-fix path.