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/references/section-structure.md

@@ -0,0 +1,63 @@
+# internal-meeting-brief — section structure
+
+Derived from the first real run (2026-09-21, APTA 2026 Booth 09-16 recap) and made
+explicit here so every future brief has the same skeleton instead of reinventing its
+structure per meeting. This is the contract — read it before generating a brief.
+
+## Always present (fixed, in this order)
+
+1. **Header** — title (meeting subject, not the raw Plaud filename), meeting date +
+   duration, prepared date, source (transcript / manual notes), mode (Agenda/Recap).
+2. **Attendees** — one card per attendee. Internal MPM people resolved by name where
+   possible. If Plaud's speaker diarization didn't resolve a name, render the literal
+   transcript label ("Speaker 1," "Speaker 3") — never guess a name. Follow with a
+   `note.info` flagging any unresolved speakers explicitly, so it's visible, not buried.
+3. **Topics Covered** — a `cards` grid, one card per distinct subject actually
+   discussed. Card count and grid density (c2/c3/c4) follow the number of real topics —
+   don't pad to hit a round number, don't force unrelated topics into one card to save
+   space.
+4. **Key Decisions** (recap) or **Discussion Plan** (agenda) — decisions actually made
+   (recap) or points to be raised (agenda). Use `quad` when there are 3-5 distinct,
+   roughly parallel decisions; use plain prose or a `note` when there's only one or two,
+   since forcing a single decision into a quad grid wastes space and implies false
+   parallelism.
+5. **Open Items** — an `actions` table with status pills. Every action item needs an
+   owner field even if the honest value is "Unassigned" — never leave the column blank,
+   since a blank reads as "forgotten to track" rather than "no owner yet."
+6. **Notes & Flags** — one `note` per genuinely separate concern: data-source
+   limitations encountered (a failed pull, a missing transcript), naming/identity
+   uncertainty, anything that needed a judgment call worth surfacing rather than
+   silently resolving. This section exists specifically so the never-fabricate rule has
+   somewhere to put its flags, visibly, not as a footnote.
+
+## Present only when content genuinely calls for it (dynamic)
+
+A dynamic section is content that has a **specific internal structure** the fixed
+sections above would flatten into an unreadable wall of text or an over-long table row.
+Add one only when the meeting's actual content has this shape — never as decoration,
+never because a template "should" have variety.
+
+| If the content is... | Use... | Real example |
+|---|---|---|
+| A sequential, ordered process (3+ steps, each depending on the last) | `flow` | Anti-vandalism 3-tier escalation (09-16 meeting) |
+| A named component/system with distinct sub-parts worth breaking out | `layerbox` + `filepill` | (not yet exercised on a real internal-meeting-brief; seen in development-brief-flavored source material) |
+| A genuine two-sided contrast (us/them, before/after, keep/avoid) | `compare` | (not yet exercised on internal-meeting-brief; used in vendor-partner-style source material) |
+| A spec/BOM-style matrix with yes/no or multi-column comparison | `unitgrid` | (not yet exercised) |
+| A handful of headline numbers worth calling out at a glance | `specbar` | (not yet exercised on internal-meeting-brief) |
+
+**Rule of thumb:** if you're reaching for a dynamic section and can't point to the
+specific part of the meeting that has this shape, don't add it. The fixed six sections
+above should carry ordinary meeting content on their own. Dynamic sections are earned
+by unusual content structure, not added for visual variety.
+
+## What's still unproven
+
+This contract is based on exactly one real run. It hasn't been tested against:
+- Agenda mode (only recap mode has run for real)
+- A meeting with genuinely no clear "topics" (a single-subject deep-dive)
+- A meeting needing more than one dynamic section
+- A recurring topic's second brief (pre-fill/delta-confirm behavior for attendees,
+  per CW-027 Concept.md, hasn't been exercised — the 09-16 brief was a topic's first
+  run, full interview by necessity)
+
+Revise this file after the second real run rather than treating it as settled.