// Convert a raw multi-speaker meeting transcript into structured meeting notes for downstream follow-up, with optional topic-level fan-out when the meeting contains multiple independent discussion blocks.
| name | meeting-grounding |
| description | Convert a raw multi-speaker meeting transcript into structured meeting notes for downstream follow-up, with optional topic-level fan-out when the meeting contains multiple independent discussion blocks. |
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:
Use this skill when:
Do not use this skill when:
A plain text meeting transcript.
The transcript may contain:
This skill always produces a meeting-level grounding note.
Always produce:
grounded.md
This file must follow the meeting grounding schema below.
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.
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
- ...
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.
Before writing outputs, first read the transcript holistically and decide whether the meeting is:
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.
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):
Multiple work items discussed by the same or different speakers must NOT be merged into one topic, even if:
Each topic has exactly ONE identity:
If a discussion covers multiple work items, it is MULTIPLE topics.
Do not split topics merely because of:
These are at most weak supporting signals.
Only create a new topic block when there is strong evidence that the meeting has shifted to a different discussion unit, such as:
grounded.md.topic_manifest.jsonchild_outputs/topic_xx/grounded.mdIf multi-topic outputs are created, write a topic_manifest.json file that records:
topic_idtopic_ground_idtitlestart_turnend_turnstart_time if recoverableend_time if recoverableconfidenceboundary_reasontopic_summarysearch_keywordschild_grounded_pathOnly include something here if it was clearly settled in the meeting. If it was only proposed, discussed, or favored, do not treat it as a conclusion.
Only include constraints or risks that were explicitly stated or strongly evidenced. Do not infer hidden constraints from weak hints.
Only include follow-up actions that were explicitly discussed or strongly implied. Do not invent action owners, deadlines, or firm commitments.
Use specific noun phrases that are useful for later search. Avoid generic terms such as:
For multi-topic meetings, topic-specific search keywords should be attached to each topic in topic_manifest.json and reflected in each child grounded note.
/meeting-grounding
Unpack a ZIP archive, inventory its files, run the corresponding child grounding skill for each supported child file, and then write a real archive-level grounded.md.
Convert a raw document into a structured grounding note for downstream research and summarization.
Run focused literature and web research from a grounded note. Use when a grounded note already exists and you want targeted research results, opened-link evidence, deeper per-paper analysis materials, optional downloaded literature, and a two-stage literature output (`lit_initial.md` then refined `lit.md`).
Review a research report draft with a structured scoring rubric, run a bounded repair loop when needed, and produce the final deliverable report.
Create a rich, evidence-preserving research report draft from a grounded note and its follow-up literature result. This is the main report-writing stage of the middle pipeline, not a compression memo.
Use the input path to select the correct downstream grounding pipeline and continue execution until the selected grounding workflow is completed.