Meeting Analyzer

Meeting Analyzer

Meetings fail at the seam between talking and tracking. The decision gets made and nobody records who approved it; the action gets stated and nobody's name lands on it; the same topic returns for the seventh week because discussing it feels productive and deciding it feels risky. This skill closes that seam with deterministic extraction — pattern rules, no model calls — and then follows the commitments across meetings to see which ones actually close.

Scope note

This is the accountability lens on meetings, not the summary lens. It extracts and tracks; it does not write the polished recap. Use it on notes that already exist, across a series, when the question is "did anything we said we would do actually happen?"

When to use this skill

• Actions keep getting dropped — items agreed in one meeting quietly reappear three weeks later, or never do
• A recurring meeting feels pointless — you need decision density and topic churn measured before proposing to cancel it
• Notes exist but no register does — months of markdown notes with decisions buried in prose that nobody can find or count
• The same topic returns every week — you need evidence of churn to force a decision owner and a deadline
• Preparing a retro or a meeting audit — completion rates and ageing per meeting show which rituals produce work that gets done
• Onboarding onto an existing project — extracting the decision log from past notes reconstructs why the system looks the way it does

Inputs the skill expects

• Meeting notes or transcripts as markdown or plain text, one file per meeting
• Ideally several meetings from the same series, so trends are visible
• An action-item register with created date, due date, owner, status and carry-over count (the parser bootstraps this from notes)
• Per-occurrence series data: attendance, duration, decisions, actions, whether an agenda was posted and notes published, and the topics covered
• The reference date for ageing calculations, if not "the newest date in the data"
• Which meeting types to exclude from decision-density scoring (retros, brainstorms, incident reviews legitimately decide little)

Clarify First

Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Whether owners and dates may be inferred — the answer is no by default; a fabricated due date enters the tracker looking legitimate and is far more damaging than a flagged gap
• Meeting type — a retro or brainstorm scored on decision density will look broken when it is working exactly as intended
• The reference date for ageing — "overdue" is meaningless without it, and pulling from the system clock makes yesterday's report irreproducible
• Who sees the per-owner output — aggregate for the team, per-person only in a 1:1; low follow-through is usually over-assignment, not under-delivery

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Extract an accountable register from raw notes

1. Point the parser at the notes file. It buckets every item into decisions, actions and open questions, and pulls owner and due date from each action.
2. Read the completeness rate first. Anything under 60% means the meeting produced intentions, not commitments.
3. Work the flagged gaps in the room or in the thread the same day. Asking "who owns this?" a week later means reconstructing a conversation nobody remembers, and the answer becomes whoever feels most guilty.
4. Never infer a missing owner or date. A flagged gap is the deliverable — it is the thing that gets fixed.
5. Add --strict in CI over a notes directory to fail the build when a meeting lands actions with no owner or date.

python3 project-management/meeting-analyzer/scripts/meeting_notes_parser.py \
  --input project-management/meeting-analyzer/assets/sample_notes.md \
  --format text --strict

Workflow 2 — Track follow-through across a series

1. Append each meeting's extracted actions to a register in assets/sample_commitments.json shape, keeping created, due, owner, status and carried_over.
2. Run the tracker with an explicit --as-of so the report is reproducible.
3. Read in this order: completion rate, the ageing distribution, then per meeting. Per-owner comes last and never first.
4. Act on the 30+ day band — close, reassign, or explicitly drop. An action auto-closed at 30 days that genuinely mattered gets re-opened within a week; one that nobody notices did not matter.
5. Apply the three-strike rule to anything with carried_over >= 3: re-commit with a date the owner states out loud, or drop it. There is no fourth carry.

python3 project-management/meeting-analyzer/scripts/commitment_tracker.py \
  --input project-management/meeting-analyzer/assets/sample_commitments.json \
  --as-of 2026-07-21 --format text

Workflow 3 — Diagnose a recurring meeting that decides nothing

1. Assemble 8-12 occurrences with attendance, decisions, actions, agenda and notes compliance, and the topics covered.
2. Run the diagnostic. It returns decision density, churning topics, attendance trend, and a KEEP / RESTRUCTURE / ASYNC / KILL verdict with a prescription.
3. Check the exclusions before acting — retros and brainstorms score badly by design and should be removed from the input, not accommodated by lowering the floor.
4. Take the churning topics to the room with the one diagnostic question: who can actually decide this? The answer picks the fix.
5. Fix hygiene before cancelling. A series at 30% agenda compliance has not yet been tried as a well-run meeting.

python3 project-management/meeting-analyzer/scripts/meeting_series_diagnostic.py \
  --input project-management/meeting-analyzer/assets/sample_series.json \
  --churn-threshold 3 --format text

Decision frameworks

The action-item completeness gate [PROVEN]

we, the team, someone, everyone and TBD are never owners, even when they occupy the grammatical slot. Accepting them launders the gap instead of surfacing it.

Follow-through benchmarks [RECOMMENDED]

Carry-over predicts abandonment better than age. An item carried three times has usually been silently deprioritised by its owner but never formally dropped.