reviewing-meetings git:20260723.6c8425bA

Immutable. This exact content is served forever at /api/v1/blob/634c7a4ce3ff998b.

---
name: reviewing-meetings
description: Use when the user asks to review, process, import, catch up on, or check for newly completed meetings from a configured meeting source, including Granola; when a scheduled post-meeting review invokes it; or when the user later approves, edits, defers, or skips visible meeting-review actions. Do not use for preparing an upcoming meeting, taking live notes, maintaining a CRM, or directly creating tasks, issues, or calendar events without meeting review.
license: MIT
compatibility: Requires meeting data with stable source IDs, an approved-note source with live template and naming guidance, and an authoritative ownership map for downstream actions. Conversational suppression requires retrievable conversation history. When Obsidian owns a target, its CLI must be available.
---

# Reviewing Meetings

Turn completed meetings from the configured source into grounded proposals for
review. Granola is one supported source, not part of the workflow's identity.
Scheduled and manual entry use this same workflow. A schedule supplies timing,
not extra authority: every run remains read-only until the user reviews a
proposal.

## Resolve visible action responses first

Before choosing a source scope, determine whether the current user message only
approves, edits, defers, skips, declines, revisits, or otherwise decides actions
from a visible meeting-review bundle. If so, read
[references/applying-approved-actions.md](references/applying-approved-actions.md)
and handle that response directly. Do not query meeting sources, rediscover
meetings, or append unrelated proposals.

If the same message also explicitly asks for a new meeting check, finish the
action-response phase first. Then run discovery as a separate read-only phase;
do not use newly discovered proposals to reinterpret the earlier action
decision.

Completion: a response to visible actions was handled against that exact bundle
before any separately requested discovery began.

## Select the source scope

For a manual request, use the named meeting or time range. If neither is given,
use the inclusive 168-hour interval ending at the query time. For a scheduled
request, use the supplied range or the same 168-hour default. Compare boundary
times as absolute instants. The overlap is intentional because eligibility
comes from observable source state, not a last-run cursor.

Read [references/source-interpretation.md](references/source-interpretation.md)
before retrieving meeting data.

Completion: the run has a bounded source window and has loaded the source
interpretation rules.

## Discover and classify meetings

Retrieve meetings in the source scope, then classify every returned meeting
from observable source state. Once a meeting is source-ready, use its source
name and stable native ID as its exact identity. A waiting meeting may not have
a stable ID yet. A meeting is eligible only when it has ended, has a stable ID,
and contains enough source material for a grounded proposal.

Use the disposition definitions and precedence in the source-interpretation
reference. Compare exact source names and IDs against approved notes and, when
retrievable, visible proposal lifecycles and dismissals in this conversation.

Completion: every discovered meeting has one observable disposition, and no
cursor, ledger, database, state file, transcript archive, or generated marker
was created.

## Prepare only new proposals

Before preparing any newly proposed meeting, read
[references/action-routing.md](references/action-routing.md)
and [assets/review-bundle.md](assets/review-bundle.md). Use the asset for every
meeting proposal and the reference to resolve one authoritative destination for
each supported action. Populate every applicable field in the asset, shape the
preview with the configured live template, and leave unsupported details
explicitly unresolved.

Keep the proposal inside the conversation. Do not create or edit a meeting note
while preparing it. Present all newly proposed meetings from this run together,
grouped by meeting. Later runs append only newly eligible meetings; they do not
repeat, renumber, or recompute older pending or deferred proposals. They may
add one terse count or reminder that older work remains pending. A fully
decided visible bundle remains suppressed by its conversational disposition
rather than becoming a new proposal again.

If current conversation history is unavailable, disclose that pending and
reviewed or dismissed suppression cannot be verified. Continue using exact
source-and-ID checks against approved notes, and do not claim the result is free
of conversational duplicates.

Completion: the bundle contains every and only newly proposed meeting from this
run, or states that there is no new meeting to review.

## Route and bind proposed actions

Follow the action-routing reference and review-bundle asset. They define the
supported categories, canonical ownership checks, proposal fields, numbering,
dependencies, and approval presentation. Omit any category whose evidence or
destination is unresolved.

Completion: every proposed action is complete enough to approve independently,
has one authoritative destination, and exposes every prerequisite.

## Apply only exact approvals

On a later user response, follow
[references/applying-approved-actions.md](references/applying-approved-actions.md)
before writing. That reference owns approval binding, pre-write rereads,
atomicity, dependency order, readback, retry boundaries, and application
outcomes.

Completion: each decided action has one readback-backed outcome or an explicit
safe stop, and no action was redirected, duplicated, or retried blindly.

## End explicitly

End the read-only run as one of:

- **Ready for review:** one or more new meeting proposals are waiting for the
  user.
- **Nothing new:** every discovered meeting was already pending, already
  approved, reviewed, or dismissed in this conversation.
- **Waiting for source:** no meeting is ready, but at least one may become
  eligible when source processing or the meeting finishes.
- **Partial:** useful proposals were prepared, but a named source or continuity
  gap limits part of the result.
- **Unable to prepare:** the run could not establish trustworthy meeting
  identity or content.

When outcomes are mixed, use **Partial** if at least one useful proposal exists
and another meeting or continuity check is limited. With no useful proposal,
prefer **Waiting for source** when every unresolved meeting may become ready
later; use **Unable to prepare** when any collision or required check needs
intervention. Use **Nothing new** only after a successful query with no new or
unresolved meeting.

Summarize the count for each observed disposition. A scheduled run stops after
presenting the read-only result and waits for the user; firing the schedule does
not approve any durable change.

Completion: the ending matches the classified meetings, identifies any limit,
and leaves every durable change unapplied.