meeting-decisions

name

meeting-decisions

description

Extract incremental meeting minutes from transcripts or Feishu documents. Focuses ONLY on discussion-generated information: decisions reached through debate, unresolved disagreements, and action items with assignees. Use this skill whenever the user provides a meeting transcript (text, Feishu doc URL, or audio transcription) and wants meeting minutes, action items, or a summary of what was decided. Also trigger when user says "会议纪要", "会议总结", "整理一下会议", "meeting notes", "meeting summary", "what was decided", or similar.

Meeting Minutes — Incremental Extraction

Transform meeting transcripts into concise, actionable meeting minutes that capture ONLY what the meeting produced — not what was presented.

Core Principle: Minutes ≠ Transcript Summary

The single most important rule: meeting minutes record what was discussed and decided, not what was presented.

A meeting typically has two types of content:

1. Presentation content — someone walks through a document, introduces features, describes status. This information already exists in the source document/PRD/slides. Restating it in minutes is redundant noise.
2. Discussion content — people debate, disagree, reach consensus, raise concerns, assign tasks. This is the incremental value the meeting created.

Only type 2 belongs in meeting minutes. If something was mentioned but nobody reacted, debated, or decided on it, it does not go in the minutes.

How to distinguish:

• One person talking for an extended stretch = presentation (skip)
• Multiple people going back and forth on a point = discussion (capture)
• Someone raising a concern or question that changes the plan = discussion (capture)
• Someone saying "好的/没问题/明白" to acknowledge info = NOT discussion (skip)
• Someone saying "不对/我觉得应该/有个问题" = discussion begins (capture from here)

Step 1: Obtain the Transcript

Accept input in these forms:

• Feishu document URL — use lark-cli or feishu-doc-reader to fetch content
• Raw transcript text — use directly
• File path — read the file

For Feishu documents, extract using:

npx @larksuite/cli api GET /open-apis/docx/v1/documents/<doc_token>/raw_content

Step 2: Identify Discussion Points

Scan the transcript for moments where:

• Someone disagrees with a proposal ("不对", "我觉得不应该", "有个问题")
• Someone asks a clarifying question that leads to a substantive answer
• Multiple participants go back and forth on a topic
• A decision is explicitly made ("那就这样", "最终决定", "OK 那我们就...")
• Something is explicitly deferred ("这个再定", "下来再讨论", "后面再说")

For each discussion point, extract:

• What was the original proposal or question?
• What was the problem or debate? (the actual back-and-forth, not just the conclusion)
• What was the outcome? (decision reached / deferred / assigned to someone)

Pay special attention to secondary conclusions within a discussion — a single discussion thread may contain multiple decisions. For example, a debate about testing costs might conclude with both "the cost model" (who pays) AND "the optimization approach" (how to reduce cost). Capture all conclusions, not just the most obvious one.

Ignore:

• Status updates with no debate
• Feature walkthroughs where everyone just says "好的"
• Greetings, small talk, technical setup ("能听到吗")
• Content that merely restates what's already in a referenced document

Step 3: Identify Action Items

Look for explicit commitments:

• "我回去跟他们碰一碰" → action item for that person
• "你出个原型" → action item for the person addressed
• "这个需要再定一下" → action item, note who owns it

Each action item needs:

• Who — the assignee (use @name format)
• What — specific deliverable, not vague ("确认阶梯定价方案" not "想想定价的事")

Assignee detection tips:

• The person speaking is often assigning to someone else — "你出个原型给开发" means the person addressed owns the action, not the speaker
• If person A says "那我回去碰一下", person A is self-assigning
• If person A says to person B "你把这个方案细化一下", person B is the assignee
• If a task is discussed but no clear owner, assign it to the person whose domain it falls under based on context (e.g., product decisions → product person, UI design → designer)

Step 3.5: Identify CC List

Scan for:

• People who attended but had no action items (e.g., someone who only said "没有问题" when asked)
• People mentioned by name as stakeholders who should be informed (e.g., "老板上次还说来呢")
• When in doubt about whether someone is CC or assignee, check if they have a concrete deliverable — if not, they're CC

Step 4: Output Format

Use this exact structure. Be concise — each discussion point should be 3-5 lines, not a paragraph.

## 会议重点/需同步讨论点

1. [Discussion topic title]
   - 原方案：[what was originally proposed]
   - 问题：[what concern/disagreement was raised]
   - 最终决定：[decision] / 未决定，[reason and what needs to happen next]

2. [Next topic...]
   ...

## 会后待办

- [Specific action item] @assignee
- [Specific action item] @assignee
- ...

c.c @[stakeholders who should be informed but have no action items]

Formatting rules:

• Discussion points are numbered, each with a clear title
• Each point has 2-3 sub-bullets: original proposal, problem, decision
• Action items use @name for assignees
• Include a CC list for stakeholders mentioned or present but without action items
• The entire document should fit on one screen — if it's longer, you're including too much

Quality Checklist

Before outputting, verify:

• Every discussion point involves at least 2 speakers going back and forth
• No point is merely restating document content that was presented without debate
• Each "最终决定" accurately reflects what was actually agreed, not what was proposed
• Action items have specific assignees, not "团队" or "大家"
• The minutes would make sense to someone who missed the meeting but has access to the referenced documents
• Total length is under 1 page — ruthlessly cut anything that doesn't pass the "was this actually discussed?" test

Common Mistakes to Avoid

1. Listing every feature/module mentioned — If someone walks through 20 features and nobody debates them, none of them belong in the minutes. The document already has that list.

2. Confusing "acknowledged" with "decided" — Someone saying "好的/明白/没问题" is acknowledging, not deciding. A decision requires a question or disagreement that got resolved.

3. Including the wrong assignee — Pay attention to who is addressed ("你出个原型给开发"), not just who is speaking. The speaker is often assigning to someone else.

4. Being too verbose — Meeting minutes should be scannable in 30 seconds. If someone needs to read for 5 minutes, you've written a summary, not minutes.

5. Missing the CC list — People mentioned or present who don't have action items should be CC'd so they know they're in the loop.