Meeting Grounding

Meeting Grounding

Convert a raw meeting transcript into a structured meeting grounding output.

This skill is for meeting grounding, not a narrative recap. It should produce a stable intermediate note that is easy to read and easy for downstream skills to use.

This skill supports both:

• single-topic meetings
• multi-topic meetings where the transcript contains multiple discussion blocks that should be researched separately downstream

When to Use

Use this skill when:

• the input is a raw meeting transcript
• the transcript is noisy, repetitive, or multi-speaker
• you need structured meeting notes before follow-up work

Do not use this skill when:

• the input is already a structured memo or action-item list
• the task is to write a polished final report
• the input is not a meeting/discussion transcript

Input

A plain text meeting transcript.

The transcript may contain:

• speaker labels
• timestamps
• interruptions
• repeated phrases
• incomplete sentences
• filler language
• partial or ambiguous decisions

Output

This skill always produces a meeting-level grounding note.

Required output

Always produce:

grounded.md

This file must follow the meeting grounding schema below.

Optional multi-topic outputs

If the meeting clearly contains multiple independent topic blocks that should be researched separately downstream, also produce:

topic_manifest.json
child_outputs/topic_01/grounded.md
child_outputs/topic_02/grounded.md
...

Do not create topic children unless there is strong evidence that the meeting contains multiple discussion blocks that should remain separate for downstream research, summary, review, and reporting.

Meeting-level grounded.md schema

Return markdown with exactly these sections. If a section has no reliable evidence, write None identified.

# Meeting Grounding

## 1. Meeting Topic
[2–4 sentence statement of the meeting’s main topic and purpose.
If the meeting genuinely contains multiple distinct topics, summarize the overall meeting scope at a higher level.]

## 2. Main Discussion Points
- [One bullet per major discussion block or major sub-topic]

## 3. Key Conclusions
- [Only items explicitly agreed, decided, confirmed, ruled out, or clearly deferred]
- [If none: None identified]

## 4. Constraints / Risks
- [Only constraints or risks explicitly stated, or strongly supported by repeated evidence]
- [If none: None identified]

## 5. Disagreements or Unresolved Issues
- [Preserve disagreements, uncertainty, and open questions]
- [If none: None identified]

## 6. Suggested Next Steps
- [Concrete follow-up actions or suggested follow-ups grounded in the transcript]
- [Do not invent owners, deadlines, or commitments]
- [If none: None identified]

## 7. Search Keywords

### Problem Keywords
- ...

### Method / Solution Keywords
- ...

### Domain / Constraint Keywords
- ...

Topic-level child grounded.md schema

If topic children are created, each child grounded note must also follow the same meeting-grounding schema exactly.

Do not invent a new topic schema.

Each child grounded note should cover only its own topic block, not the entire meeting.

Topic segmentation rule

Before writing outputs, first read the transcript holistically and decide whether the meeting is:

• a single-topic meeting, or
• a multi-topic meeting with multiple independent discussion blocks

A new topic block should be created only when the discussion has shifted to a different topic that would reasonably require separate downstream research.

This is a semantic judgment, not a simple surface-rule split.

Topic segmentation hard constraints (MUST follow)

Constraint 1: Same person, different work → Must split

When one speaker transitions from one work item to a completely different work item, create a new topic regardless of discussion duration or depth.

Indicators of different work (create new topic):

• Switching from Project A to Project B
• Switching from Experiment X to Experiment Y
• Switching from Tool development to Paper writing
• Any transition between distinct tasks with no direct dependency

Constraint 2: Different work → Never merge

Multiple work items discussed by the same or different speakers must NOT be merged into one topic, even if:

• They are discussed consecutively
• They share similar technical domain
• They belong to the same team member
• They are briefly mentioned together

Constraint 3: Topic identity rule

Each topic has exactly ONE identity:

• One distinct work item
• One primary contributor
• One set of follow-up actions

If a discussion covers multiple work items, it is MULTIPLE topics.

Strong rule: do not split on weak signals alone

Do not split topics merely because of:

• speaker changes
• interruptions
• Q&A turns
• short digressions
• brief examples
• clarification exchanges
• repeated restatements
• agenda phrases without a real shift in discussion target

These are at most weak supporting signals.

What counts as a real topic shift

Only create a new topic block when there is strong evidence that the meeting has shifted to a different discussion unit, such as:

• a different project, paper, system, workstream, or case
• a different primary problem or decision target
• a different set of follow-up research needs
• a sustained new discussion block rather than a brief aside