Meeting Sync

Pulls meetings from the user's transcript/summary tool and writes them to the corresponding day's Logseq journal as structured meeting blocks. Each meeting block carries its tags and metadata as same-block properties (tags::, type::, attendees::) written directly under the title line — exactly like the /template meeting output. The tool's AI summary IS the meeting note — don't pull raw transcripts.

Two things the properties do:

• tags:: meetings groups the note — it's what lands under the All meetings view (and <work-hub> puts it on the work hub too).
• type:: facets it — the 1:1s and Interviews views query (property type "1on1") / (property type interview), so a meeting only appears under a facet if it carries the matching type::.

Values: type::/status:: are scalar — write them bare (type:: 1on1). tags::/attendees:: hold page references. If a freshly written note doesn't show on its hub, re-index the graph once (Logseq graph menu → Re-index) — API/file writes can lag Logseq's live index.

The skill also scans the summary for durable rules (system behaviour decisions, debugging insights, agreements) and surfaces them in a ## Key insights section at the top of the meeting block, adding the topic page to tags:: so the rule is findable on the topic hub later.

Invocation modes

• /meeting-sync — most recent meeting
• /meeting-sync today — all meetings from today
• /meeting-sync 2026-06-12 — all meetings on that date
• /meeting-sync "Alice 1:1" — search by title
• /meeting-sync new — everything since the last sync (reads the Meeting Sync page, see step 7)
• Natural language counts: "import yesterday's meetings", "sync standup", "save my meetings to logseq", "sync everything since last time"

If nothing specified, default to the most recent meeting.

Provider detection (with persistence)

The user's tool choice is stored on the meetings hub page as a meeting-tool:: property (e.g. meeting-tool:: granola). This means detection only happens once.

0. Check for saved preference

Read the meetings hub page via mcp__mcp-logseq__get_page_content("meetings"). If it contains a meeting-tool:: property, use that tool and skip to the Steps section.

Known values: granola, otter, fireflies, fathom, tldv, manual.

If no meeting-tool:: property exists, proceed to step 1.

1. Check available MCP servers

Look for known meeting tool MCP servers already connected:

If exactly one meeting tool MCP is found, use it. If multiple are found, ask the user which one to use. If none are found, go to step 2.

2. Ask the user

Which tool do you use for meeting transcripts/summaries?

1. Granola
2. Otter
3. Fireflies
4. Fathom
5. tl;dv
6. Other (tell me the name)
7. None — I'll paste summaries manually

If your tool has an MCP server, I'll need it connected first.

3. Save the choice

After the tool is determined (from step 1 or 2), add meeting-tool:: <tool> to the meetings hub page via mcp__mcp-logseq__update_page. Append it as a property line. Next time the skill runs, step 0 finds it and skips detection entirely.

If the user chose "None / manual", save meeting-tool:: manual.

Manual paste — always available

Regardless of the saved tool, if the user pastes a meeting summary directly (or says "here are my meeting notes"), skip MCP calls and structure what they gave you. Don't ask "but you have Granola configured, want to use that instead?" — just process the paste.

This covers: meetings the tool didn't record, calls from a different app, notes from a phone call, or the MCP being temporarily down.

Provider-specific notes

Granola

• list_meetings accepts time_range: "custom" with custom_start + custom_end. Date format YYYY-MM-DD.
• get_meetings returns summary (markdown). The summary IS the note content.
• summary can be literal "No summary" when the tool hasn't processed the meeting yet. Insert the block anyway with the line "No summary available yet."
• No separate action_items field. Action items live in the summary markdown, usually under "### Next Steps" or "### Action Items". Convert those bullets to TODO blocks when writing.
• Don't call get_meeting_transcript. Raw transcripts add noise.
• known_participants entries are Name <email> or Name from Org <email>. The "(note creator)" entry is the user — skip it.
• Strip Granola's escape characters. Markdown like \~30 minutes should become ~30 minutes. Backslash-escaped chars are formatting artifacts.

Other tools (Otter, Fireflies, Fathom, tl;dv, etc.)

When an unfamiliar MCP server is detected:

1. List its available tools via the MCP tool listing
2. Identify the "list meetings" and "get meeting detail" equivalents
3. Call them and map the response fields to what this skill needs: title, date/time, summary/notes, attendees/participants
4. Proceed with the same block format below

The block format, attendee resolution, key insights extraction, and TODO discipline are identical regardless of which tool provides the data.

Steps

1. List meetings

Use the provider's list call with appropriate date filtering.

For new: read the Meeting Sync page and fetch from its last-sync:: date through today. Start on the last-sync day itself, not the day after — meetings later that day may have landed after the last run; the idempotency check (step 4) skips the ones already written. If the page doesn't exist, there's no previous new run: say so and ask for a start date instead of guessing.

2. Resolve attendees → people pages

Parse the attendees list from the provider. Skip:

• The meeting creator/host entry — that's the user
• Group emails (group.foo@...)

For each remaining attendee:

1. Lowercase firstname → people/<firstname>
2. If firstname collides with someone already in the user's graph (different person, same firstname), use people/<firstname>-<lastname-initial-or-full>. Example collision: Alice Smith vs Alice Lin → people/alice and people/alice-l.
3. Check the existing people/* namespace via list_pages to detect collisions and reuse existing pages.
4. If page doesn't exist, create it as a stub with these page properties:

   tags:: system
   exclude-from-graph-view:: true
   company:: 
   role:: 

   If you can infer the company from the attendee's email domain (e.g. @stripe.com → [[companies/stripe]], internal domain → [[acme]]), set company:: accordingly. The user can flesh it out later.

3. Compute journal page name

Logseq journal format: <MonAbbr> <D><ordinal>, <YYYY>.

• Months: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
• Ordinals: 1st, 2nd, 3rd, 4th–20th use "th", 21st, 22nd, 23rd, 24th–30th use "th", 31st use "st"

Examples: Jun 12th, 2026, Jan 1st, 2026, Mar 23rd, 2025.

4. Idempotency check

Before writing, check the journal page for an existing meeting block with the same title. If a meeting block with that title (carrying tags:: meetings) already exists on that journal date, ask the user whether to skip or overwrite.

4a. Scan summary for durable rules — REQUIRED

Meeting summaries often contain durable knowledge buried in the discussion: decisions made, system rules clarified, debugging insights shared. These should be surfaced at the top of the meeting block, not buried in the summary markdown.

Strong rule signals (extract if present):

• "We decided X" / "Going forward, X" — durable decision
• "By design, X works like Y" — system rule
• "The rule is X" / "X always means Y" — explicit rule statement
• Explicit "Decision:" / "Agreement:" / "Conclusion:" markers in the summary
• Trade-off comparisons with a chosen path

Skip these (not durable rules):

• Routine status updates ("Bob deployed X")
• In-progress work ("working on Y")
• Personal opinions without group agreement ("I think X")
• Discussion items without resolution

When strong rule signals are detected, add a ## Key insights section as the FIRST child of the meeting block, and add the topic page(s) to the block's tags::. When no rule signals exist, skip the section.

4b. Note voice — notes, not docs

Applies to everything the skill writes in its own words: Key insights bullets, block titles, rewritten action items. (The provider summary itself is preserved as-is.)

Notes are terse and personal — the reader is future-you, not a newcomer. Cut:

• Hand-holding phrases ("for the user", "must be... to qualify") — just state the rule
• Redundant restatement ("by design" AND a quote confirming it — pick one)
• Markdown emphasis (**bold**, *italic*)
• Long sentences — bullet over 12 words? Try cutting half

Word swaps: "implemented" → "added"/"did", "leveraged"/"utilized" → "used", "in order to" → "to", "applies to" → "needs".

Plain language over code jargon: drop ClassName#method, table/column names unless the rule hinges on that exact name. Keep numeric thresholds — those are signal.

Bad: "The feature only applies to users meeting condition X and condition Y — this is by design." Good: "feature needs X AND Y. Otherwise = no go."

Match the user's tone. Informal in, informal out. (Full version: logseq-note skill, "Notes are notes, not docs".)

4c. Scan summary for brag signals — ASK before tagging

Meeting summaries often record a win the user forgot to log: something shipped, led, delivered, or a bug correctly diagnosed. Don't auto-tag these — brag is subjective, so surface the candidate and let the user decide.

Brag signals attributable to the user (case-insensitive, the user's own work):

• "shipped" / "deployed" / "launched" / "delivered" / "merged" (esp. with PR numbers)
• "led" / "drove" / "owned" (a migration, launch, incident)
• "mentored" / "onboarded"
• "reduced [latency|cost|time]" / "saved [hours|days|$]" — keep the number
• User proving something isn't a bug (correct diagnosis = brag)

Unattributed wins — surface as candidates too (don't assume, ask). AI summaries often strip attribution: the user's best wins show up as ownerless bullets — Idea:, Decision:, Proposal:, or a win-signal bullet with no name attached. Don't skip these because ownership can't be confirmed; include them as candidates and let the prompt confirm ownership. (Real miss this guards: an "Idea: use X to do Y" bullet that was actually the user's suggestion.)

Skip (same as brag-finder): bullets explicitly owned by a named teammate, "tried but failed", "started working on" (incomplete), pure coordination ("synced with X"), canceled items.

Dedup against already-logged brags. Before prompting, read the target journal day and skip any candidate already captured in a block tagged brag (the user may have logged it manually, or logseq-note/brag-finder did). Match on gist, not exact wording.

When candidates survive, ask once per meeting — a multi-select question if your agent supports one — with one option per candidate (label = terse note-voice title, description = verbatim summary phrasing), and let the user reject all:

Brag? This meeting has win-like activity. Tag any as brag?
  [ ] <terse win 1> — "<verbatim summary phrasing>"
  [ ] <terse win 2> — "<verbatim summary phrasing>"

Only ask when signals exist — never prompt on a routine status meeting. If the user picks none, add no brag tag.

On confirmation: add brag to the meeting block's tags:: line (tags:: meetings, brag, <work-hub>). The meeting block surfaces on the brag hub — no separate brag block, no what-i-did::/impact:: scaffolding (that's brag-finder's job; here the meeting block is the record). Title stays note-voice per 4b.

5. Write the journal block

For each meeting, append one block to the journal page (mode=append). When syncing multiple meetings same day, order chronologically ascending (earliest first) so the journal reads top-to-bottom through the day. Add an empty block between meetings as a visual separator.

Formatting: write the tags and metadata as same-block properties — un-dashed key:: value lines directly under the title bullet — so they attach to the parent (title) block. Do not put them on dashed child bullets — that makes them separate blocks. Tag values in tags:: are bare (meetings); attendees:: values are [[bracketed]] page references. Scalar values like type:: stay bare.

Block format (with rule signals detected):

- {Title} — {HH:MM}
  type:: 1on1
  attendees:: [[people/x]], [[people/y]]
  tags:: meetings, <work-hub>, <work-hub>/<topic-1>, <work-hub>/<topic-2>
  - ## Key insights
    - <rule 1, terse, like a note not docs>
    - <rule 2>
  - ## Summary
    - {summary content, preserved}
  - ## Action items
    - TODO {action item assigned to user}
    - {action item assigned to someone else}
-

- {Next meeting title} — {HH:MM}
  ...

Block format (no rule signals, plain meeting):

- {Title} — {HH:MM}
  attendees:: [[people/x]], [[people/y]]
  tags:: meetings, <work-hub>
  - ## Summary
    - {summary content, preserved}
  - ## Action items
    - TODO {action item assigned to user}
    - {action item assigned to someone else}

Notes:

• tags:: does the grouping. Always include meetings. Add <work-hub> based on attendee email domain. Add <work-hub>/<topic-X> for each topic surfaced in step 4a's rule extraction — this is what makes the rule findable later via topic hubs.

• type:: does the faceting — REQUIRED for 1:1s and interviews. Classify the meeting and set type:: so it lands under the right facet on the meetings hub:

  • 1on1 — exactly one counterpart (you + one other person), reads like a recurring/individual catch-up. Single-name titles ("Alice 1:1", "Catch-up with Bob") are strong signals.
  • interview — a candidate evaluation. Title or context names a candidate/role.
  • generic meeting (standups, group syncs, planning) — omit type::; it still shows under All meetings, just not a facet. Optionally set a value the meetings hub lists under type-values:: (e.g. standup, sync).

  Write the value bare — type:: 1on1. The leading digit only needs quoting on the query side ((property type "1on1")), which the hub already does; the stored property value is the plain string.

• attendees:: aggregates by person. Comma-separated [[people/x]] references. Backlinks on each person page surface every meeting with them (entity-aggregator pattern) — no "series" page needed.
• Action items: TODO only for today's meetings, and only if the user owns the item. For a meeting dated today: if the parenthetical assignee includes the user's first name (e.g. (Alice) or (Alice + Bob), assuming the user is "Alice") or there's no assignee, prefix with TODO. If assigned to someone else only (e.g. (Bob), (Charlie)), leave as plain bullet. Only substantive tasks (code, builds, non-trivial investigations) get TODO — coordination ("sync with Bob"), admin steps ("create a ticket"), and same-session one-offs stay plain. For a meeting on any earlier day, write every action item as a plain bullet: by sync time it's already tracked elsewhere or done, and a stale TODO is noise.
• No tool-specific ID properties, no source attribution. Match by title + date for idempotency. Don't add "synced from Granola" lines.

6. Confirm

Report concisely:

Synced N meetings to [[Jun 12th, 2026]]:
- {title 1} ({HH:MM}) — N attendees
- {title 2} ({HH:MM}) — N attendees
{K people stubs created}

7. Stamp the sync (new only)

After a new run writes its meetings, record the run on the Meeting Sync page with update_page (mode: replace, overwriting the previous stamp). If the page doesn't exist yet, create it with create_page. new reads last-sync:: from here.

tags:: system
exclude-from-graph-view:: true

- last-sync:: {YYYY-MM-DD}
- range:: {start-date} → {end-date}
- meetings-synced:: {N}

• last-sync is today's date. range is the date window fetched. meetings-synced is the count written this run.
• Only new stamps. It's the one mode that covers an unbroken range up to today; stamping after a single-date or most-recent sync would move last-sync past days that were never synced.
• Machine-written status record — no prose or commentary on this page.

Entity-aggregator patterns (do follow)

• Entity is the aggregator. Each meeting is one block in that day's journal. The attendee link does the grouping automatically — open people/<person> to see every meeting with them. No "series" page needed for recurring 1:1s.
• One block per occurrence. Don't merge weekly stand-ups into one page. Each day's stand-up is its own block in that day's journal.

Hard constraints

• Default to journal blocks, not dedicated pages. Only create a separate page if the user explicitly asks.
• No transcript dumping. The tool's summary is the source of truth. Never pull raw transcripts.
• No source attribution. No "synced from X" lines, no tool-specific ID properties. Just the meeting content.
• Strip formatting artifacts. Tools often add escape characters (e.g. \~30 minutes → ~30 minutes). Clean them.
• TODO discipline. Only today's meetings produce TODOs, and only for the user's own substantive tasks. Past meetings are reference notes. Everyone else's work stays as plain text bullets.
• Tag and facet via same-block properties. tags:: meetings (+ <work-hub>/topics, all bare) groups; type:: 1on1/interview (bare) facets. Write them as un-dashed lines directly under the title so they attach to the parent block. Generic meetings need no type::.

Worked example

Input: /meeting-sync today on Jun 12th, 2026 — found 3 meetings

Example A — meeting with rule signals detected (user is "Alice"; teammates Bob, Charlie):

- Team Standup — 13:30
  attendees:: [[people/bob]], [[people/charlie]]
  tags:: meetings, <work-hub>, <work-hub>/<topic>
  - ## Key insights
    - <rule extracted from discussion, terse, note voice>
    - <another rule if surfaced>
  - ## Summary
    - ### <work area> update (Bob)
      - PR merged and deploying, live shortly
      - Next: extend to <next area>
    - ...
  - ## Action items
    - TODO Retest <feature> end-to-end (Bob + Alice, in ~1 hour)
    - Deploy <feature> to <env> once current build is live (Bob)
    - TODO Help Charlie parallelize <task> (Alice)

The Key insights section surfaces durable rules at the TOP of the meeting block, so they're visible without scrolling through the summary. The topic page in tags:: (<work-hub>/<topic>) makes those insights findable on the topic hub later. This standup is a group meeting, so no type:: — it shows under All meetings only.

Example B — a 1:1 (faceted) (user is "Alice", meeting with Bob):

- Alice / Bob 1:1 — 10:00
  type:: 1on1
  attendees:: [[people/bob]]
  tags:: meetings, <work-hub>
  - ## Summary
    - {summary as-is}
  - ## Action items
    - TODO {item}
-

- {Next meeting...} — {HH:MM}

type:: 1on1 lands this under the 1:1s facet on the meetings hub as well as All meetings. Most group meetings have no type:: — don't force one.

TODO discipline: these are today's meetings, so Alice-owned (or shared) substantive tasks are TODO; Bob-only items are plain bullets. Synced a week later, every item would be a plain bullet. The empty - between meeting blocks gives visual separation in Logseq.

People stubs created: people/bob, people/charlie (created as needed; existing pages reused).

Voice

No tool-call narration. No decorative tables or emoji. No long raw error-log dumps unless user asks. Standard tech acronyms OK (DB/API/MCP); never invent new abbreviations.

Abbreviate prose words (auth/config/req/res/fn/impl) — prose words only, never real code symbols or function names. Strip conjunctions; use arrows for causality (X → Y). One word when one word enough. Code symbols, function names, API names, error strings: never abbreviate.

No filler. No hedging. No "you", "your", "we". Keep sentences intact. Professional but tight.

Example

❌ "Of course! Let me help you sync your meetings. First I'll detect which meeting tool you use by checking your MCP servers, then I'll pull the most recent meeting."

✅ "Synced 3 meetings to [[Jun 12th, 2026]]: Standup (13:30) — 2 attendees, Customer sync (15:00) — 4 attendees, Sprint retro (16:00) — 5 attendees. 2 people stubs created."

Don't

• Don't pull raw transcripts — never needed
• Don't auto-link group emails (group.web-squad-1@...)
• Don't create top-level pages like Squad 1 Stand Up 2026-06-12 — keep meetings in journal blocks
• Don't include the meeting creator/host attendee — that's the user themselves
• Don't tag the journal page itself — tag the meeting block via its tags:: property
• Don't put tags::/type::/attendees:: on dashed child bullets — keep them as un-dashed lines under the title so they attach to the parent block
• Don't backfill old meetings without being asked
• Don't add tool-specific metadata properties to the block