meeting-notes-from-miclog

name	meeting-notes-from-miclog
description	Summarize the most recent concluded or final-minutes calendar meeting from timestamped transcripts in memory/miclog/. Use when Codex needs copy/paste-ready meeting notes from a microphone transcript plus Google Calendar metadata, attendees, event descriptions, and linked meeting docs.

Miclog Meeting Notes

Generate copy/paste-ready meeting notes from timestamped transcript Markdown files in memory/miclog/ and nearby calendar context. The transcript files are generated by miclog. Use memory/miclog/AGENTS.md as the transcript index when selecting files.

Inputs

Use whatever the prompt provides:

• Calendar event title, start/end time, attendees, description, and links.
• A bounded miclog excerpt from memory/miclog/, or enough timing information to read the right timestamped transcript file.
• Any event-linked docs that may explain agenda, project names, attendees, or decisions.

If the prompt does not include a transcript excerpt, use memory/miclog/AGENTS.md to find candidate transcript files, then read the timestamped transcript files whose meeting window overlaps the calendar event, with a small buffer before start and after end. Miclog timestamps are local time and look like [YYYY-MM-DD HH:MM:SS].

Context Gathering

1. Read the calendar event metadata first. Use the event title, description, attendees, and links to understand the meeting purpose.
2. Read linked docs that look relevant to the agenda or decisions. Prefer Atlassian Rovo MCP for Confluence links. Prefer Dropbox MCP (dropbox-mcp) paper_read_document for Dropbox Paper links, following the repository and user instructions. For Paper links, fall back to the Chrome plugin/live Paper view second when Dropbox MCP is unavailable or lacks the needed operation. Use /dropbox or sidekick.clients.dropbox only as a final fallback when Chrome is unavailable or unsuitable, DROPBOX_ACCESS_TOKEN is set, debugging the local client, running standalone workflows, or the user explicitly asks for the local client.
3. Use linked docs as context, not as a replacement for the transcript. If docs conflict with the transcript, treat the transcript as what was actually discussed.
4. Infer speaker names only when there is strong evidence from the transcript text, attendee list, event owner, or linked docs. If confidence is low, write generic notes without speaker attribution.

Output

Return only Markdown notes suitable for pasting into Confluence, email, or Slack. Do not write files, post messages, send email, or update Confluence unless the user explicitly asks. When the user explicitly asks to save a copy, create a new timestamped summary Markdown file under local/miclog/ and update local/miclog/AGENTS.md.

Use this structure:

# [Meeting title] - [YYYY-MM-DD]

## Executive Summary
[2-4 sentences covering the meeting purpose, most important outcomes, and any material risk or decision.]

## Discussion
- [Concrete topic, update, decision, or concern.]
- [Another discussion bullet.]
- [Include who owns or raised something only when high-confidence.]

## Action Items
- [ ] @Name - [specific next step, when the owner is high-confidence]
- [ ] Follow up - [specific next step, when the owner is unclear]

Quality Bar

• Be concise but specific. Prefer useful nouns, project names, dates, metrics, and decisions over generic summaries.
• Preserve uncertainty when the transcript is unclear. Use phrases like "The group discussed..." or "A follow-up was suggested..." instead of guessing speakers.
• Use Confluence-style @Name notation for action item owners only when the owner is high-confidence from calendar attendees, the transcript, or linked docs. If the owner is unclear, use Follow up instead of guessing.
• Do not include raw transcript dumps.
• Keep the notes practical: someone should be able to paste them directly into a meeting notes doc, email, or Slack thread with minimal cleanup.