Bryan Gilliom (via Claude)
c98daed984
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).
64 lines
4.1 KiB
Markdown
64 lines
4.1 KiB
Markdown
# 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.
|