--- name: internal-meeting-brief description: Generate an MPM-branded internal meeting briefing document as a single-file HTML artifact — covers internal planning sessions, executive leadership meetings, and project team meetings (e.g. APTA planning, status reviews, internal design discussions). Produces agenda-mode (pre-meeting prep, pulling the previous meeting's transcript) or recap-mode (post-meeting summary, pulling the current meeting's transcript). Always use this skill when the user asks to "brief this meeting," "recap the meeting," "prep me for [meeting]," "write up the [meeting name] meeting," or names an internal MPM meeting/topic and wants it documented or summarized — even if they don't say "internal-meeting-brief" by name or don't mention CoWork/Brief explicitly. Part of the CW-027 Brief plugin family; see git.mpm.to/mpm/brief. --- # internal-meeting-brief Generates a single self-contained HTML briefing document for an internal MPM meeting, built on Brief's shared MPM-branded component library. Does the work of assembling the brief itself — pulling from connected tools — rather than requiring the person to hand-supply meeting notes. Read `assets/brief-components.css` and `references/section-structure.md` before generating any brief. The CSS is the canonical, only source of Brief's visual language — never re-derive it inline. The section-structure doc is the fixed-vs-dynamic contract for what this skill's output actually contains. ## Prerequisites This skill uses, but does not own, the following connected tools — confirm they're reachable before starting, and degrade gracefully (see Hard Rules) if one isn't: - **Plaud** — meeting transcripts (recap: current meeting; agenda: previous meeting) - **Odoo** (MCP) — linked Project/tasks, Sales/Purchase Orders, Knowledge Base, Helpdesk tickets - **Google Workspace** (MCP) — Gmail, Google Chat, Drive, Sheets - **Google Drive** — the topic's continuity folder (`_topic-state.md` + brief history) If any of these fail outright (not just "returns nothing," but errors or times out), say so plainly in the generated brief's Notes & Flags section rather than silently omitting that source. See "Known limitation" below for a real, currently-open example. ## Workflow ### 1. Resolve the topic Every brief belongs to a project/topic, not just a meeting instance. Ask which topic/project this meeting is about if it isn't obvious from context. Search Google Drive for an existing topic folder (naming pattern: ` — Meeting Briefs`) before creating a new one. If an Odoo Project already exists for this topic and has an attached Drive folder, use that folder instead of creating a parallel one. ### 2. Read (or create) the continuity manifest Open `_topic-state.md` in the topic folder. If it doesn't exist, this is the topic's first run — create it with the schema below, and expect a fuller interview in the following steps since there's no history to draw on yet. `_topic-state.md` schema: linked Odoo Project ID / SO / PO, linked Google Chat Space, Plaud recording ID/pattern, last-meeting date, running open-items/decisions ledger, attendee list, learned spreadsheet task-registry column mapping (if this topic uses one — see step 5), brief-history log (date/type/mode/link), and a "Related documents" table for cross-referencing other MPM document types about the same real-world topic (pre-mortems, BAI build docs, etc. — see CW-027 Concept.md's rewrap-vs-harvest principle; don't merge their content into this ledger, just reference them). ### 3. Determine mode: Agenda or Recap Agenda mode (pre-meeting prep) pulls the *previous* meeting's transcript and any updates since. Recap mode (post-meeting) pulls the *current* meeting's transcript. Ask if not specified by the request. ### 4. Capture and normalize attendees - **First run for this topic:** ask who's attending / who attended. - **Recurring topic:** pre-fill from the manifest's last attendee list and ask "same as last time, or any changes?" — not a blank-slate interview. - **Recap mode with a Plaud transcript available:** prefer *actual* attendance from the transcript's speaker attribution over the pre-meeting expected list — someone who showed up unexpectedly and spoke shouldn't be treated as absent. - **Normalize into two groups:** - Internal MPM attendees — record by name for the brief; no further resolution needed (no external allowlist implications for this brief type). - External attendees (rare for this brief type, but possible) — cross-reference against Odoo contacts to resolve/confirm email addresses rather than trusting raw input. - **If Plaud's diarization didn't resolve a speaker to a name:** render the literal transcript label ("Speaker 1," "Speaker 3"). Do not guess a name from context, even when a guess feels obvious. Flag unresolved speakers in the Notes & Flags section. ### 5. Pull data, scoped to what this brief type actually needs Not a monolithic "pull everything" — internal-meeting-brief's real needs, based on the first run, are: - Plaud transcript (per mode, above) — the primary source - Gmail / Google Chat: updates since the manifest's last-meeting date, scoped by project/topic keywords, never a blanket search - Odoo Project tasks, if a linked project exists (expect this to be sparse or absent — PM-tool adoption is inconsistent; fall back to a spreadsheet task registry if the topic uses one, learned via a one-time interview on first use and stored in the manifest, never assumed to follow a universal schema) Sales/Purchase Orders and Helpdesk ticket review are not typically relevant to this brief type (they matter more to vendor-partner-brief and status-update-brief) — don't pull them by default. ### 6. Synthesize into the section structure Follow `references/section-structure.md` exactly: six fixed sections in order, dynamic sections only where the meeting's actual content has a structure that calls for one. Real, verified content over generic summary — carry forward specific facts (names, dates, exact technical decisions), not vague paraphrase. ### 7. Render Single self-contained HTML file. Include `assets/brief-components.css` inline (don't link out to it — the brief must survive as a standalone file). Include: sticky jump-nav, a working light/dark toggle (`data-theme` attribute, default light), and the `@media print` rules from the shared CSS (forces light, hides nav/toggle, avoids awkward page breaks). ### 8. Archive Save the generated HTML into the topic's Drive folder. Update `_topic-state.md`: append to the brief-history log, update the running open-items/decisions ledger (carry forward anything still open from this run), update the attendee list, update last-meeting date. ### 9. Present Hand the file to the person. Don't silently skip presenting it even if archived — the person needs to actually see and review it, not just trust it happened. ## Hard rules - **Never fabricate.** No matching Plaud recording, no linked Odoo data, an empty Gmail/Chat scan — say so plainly in Notes & Flags. A brief with visible gaps is correct; a brief with invented content to fill them is not. - **Bounded queries only.** Gmail/Chat scans are scoped by project keyword + date window from the manifest. Never an open-ended search. - **No live publishing yet.** This skill produces a local file only. Hosting/publishing (a shareable link, external access control) is CW-029 (Brief Server) — deliberately separate, deliberately not built yet. Don't attempt to stand up delivery infrastructure as part of running this skill. ## Known limitation (open as of 2026-09-21) The Plaud MCP connector has failed on every attempt so far — first appeared to be an account/workspace mismatch, but a later attempt timed out with a message indicating it runs as a **local server via the Claude Desktop app**, not a cloud connector. Confirmed still broken after Bryan verified the connector's own settings looked correct. Treat Plaud as unreliable until this is resolved — the one real brief produced so far (2026-09-16 APTA meeting) used a manually uploaded transcript as a workaround, not a live pull. Don't assume this is fixed without testing it again. ## Provenance Component library, tokens, and this workflow were derived from two real test runs (2026-09-21): a recap brief for a real APTA 2026 booth planning meeting, and a rewrap of an unrelated pre-mortem document to validate the component system against a different content shape. See CW-027's Concept.md (Drive) for full design history and the five other planned skills in this family (vendor-partner-brief, status-update-brief, five-whys-brief, kickoff-brief, development-brief) — none built yet.