Add internal-meeting-brief — first real skill in the Brief family

Real-tested 2026-09-21 against the APTA 2026 booth 09-16 planning meeting
(recap mode). Includes:
- skills/internal-meeting-brief/SKILL.md — full workflow: topic resolution,
  continuity manifest, agenda/recap branching, attendee capture/normalization,
  scoped data pulls, synthesis, render, archive.
- assets/brief-components.css — canonical shared component library (cards,
  flow, layerbox/filepill, unitgrid, quad, compare, specbar, actions+status
  pills, note callouts x4 tones, colvis/ring), MPM tokens from CW-028,
  required light/dark toggle, print rules.
- references/section-structure.md — fixed-vs-dynamic section contract,
  explicitly marked unproven beyond one real run.

Known limitation: Plaud MCP connector is currently non-functional (local
server via Claude Desktop, times out). Brief was built from a manually
uploaded transcript, not a live pull.

Five more skills planned, not started: vendor-partner-brief,
status-update-brief, five-whys-brief, kickoff-brief, development-brief.
Full design history in CW-027's Concept.md (Drive).

skills/internal-meeting-brief/SKILL.md

@@ -0,0 +1,142 @@
+---
+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: `<Topic Name> — 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.