Purpose and when to use this workflow
- Goal: Turn meeting audio/transcripts/notes or chat logs into structured minutes (agenda topics, conclusions, certainty labels, action items) and map each action to an owner, due date, and completion standard.
- Typical uses: weekly syncs, project reviews, client meetings, formal archival meetings, or any meeting where outcomes must be tracked and verified.
Four questions to answer before you start
1. Meeting type (weekly sync, review, client call, board meeting). Different types require different evidence and format. 2. Input formats available (audio, transcript text with timestamps, shorthand notes, chat logs). If you only have audio, obtain a transcript that includes timestamps. 3. Output requirements (brief summary, archive-ready minutes, action-item list, or a verification report with verbatim evidence). 4. Review process (who must confirm items, which items require human sign-off).
How to pick candidate Skills (selection strategy, not installation instructions)
- Pick based on what you most need to avoid losing or mis-stating: if you fear turning discussion into decisions, choose tools that attach certainty labels; if you fear unowned tasks, choose tools that extract and format action items.
- Run comparison tests with the same redacted meeting to evaluate topic segmentation, decision labeling, and the completeness of action-item fields.
- Insist on explicit output fields: every action item should have at least task, owner, due date, completion criteria; any missing fields must be flagged as "pending confirmation" rather than guessed.
Step-by-step operational workflow (generic template)
1. Prepare inputs: collect transcript with timestamps, agenda, attendee list, and relevant documents. Redact sensitive data where required. 2. Define the task and acceptance criteria: specify meeting type and desired output structure (e.g., agenda-based minutes, decision log, action item table), and state acceptance points (traceable evidence, complete action item fields). 3. Run the chosen Skill or apply the template manually: feed inputs and request outputs that include certainty labels and verbatim quotes or timestamps for key decisions. 4. Human review: meeting host or responsible parties verify any items labeled "confirmed/decided" or external commitments, and confirm owners and deadlines. 5. Publish and archive: after confirmation, distribute minutes and sync action items into your task system, keeping the original materials for traceability.
Worked (redacted) example
Scenario: 45-minute project review (excerpt of a redacted transcript with timestamps) Input excerpt:
- [00:05:12] PM: "Can this feature ship next week?"
- [00:05:30] EngLead: "If the backend API is done today, I think so; I need two days for integration."
- [00:06:10] QA: "We need full regression testing, about three days."
- [00:07:00] PM: "Then push release to next Friday. Who owns API delivery?"
- [00:07:15] EngLead: "Backend team owns it, Li Ming will follow up."
Sample structured output (illustrative):
- Summary (by topic)
- Topic: Release timing - Conclusion: Release date is tentative for next Friday (Status: Tentative). Evidence: EngLead says “If the backend API is done today… I need two days” [00:05:30]; QA says regression testing needs three days [00:06:10].
- Decision & certainty labels
- Release date: Tentative (requires backend API delivery and successful QA). Verbatim evidence attached.
- Action items (minimum fields)
1) Task: Deliver backend API and notify integration team Owner: Li Ming (Backend) Due date: within 2 business days (example: 2026-11-18) — if not explicitly stated, mark as "pending confirmation of exact date" Completion criteria: API documentation updated, API smoke tests passing, and a delivery confirmation posted in team channel Evidence: EngLead assignment at [00:07:15] 2) Task: Full regression testing Owner: QA team (specific person pending) — if not assigned, mark as "pending confirmation" Due date: 3 days of testing (start/end dates to be confirmed with owner) Completion criteria: All critical test cases passed and test report submitted
Suggested follow-up actions:
- Host contacts Li Ming to confirm a concrete API delivery date and updates the minutes.
- QA assigns a responsible tester and sets test start/end dates; minutes are updated accordingly.
Pre-release checklist (must pass before circulation)
- Are important conclusions labeled with certainty (confirmed/tentative/proposed/pending)?
- Does each important claim include a verbatim quote or timestamp for traceability?
- Do all action items include task, owner, due date, and completion criteria? Are missing fields explicitly marked "pending confirmation"?
- Have high-risk or external commitments been confirmed by named people?
Known limitations and risks (explicitly stated)
- Automated outputs are not a substitute for formal, signed decisions. High-impact commitments or personnel judgments require human confirmation before recordation or external communication.
- If the input lacks timestamps or high-quality transcription, traceability and precise quotation are limited; obtain a timestamped transcript when possible.
- Tools may misclassify discussion as a decision. Use certainty labels and human review for any item labeled "confirmed".
- Sensitive information must be handled under your organization’s data and permission policies; redact before uploading or test in a controlled environment.
Recommended next steps
1. Run candidate Skills on a single redacted past meeting and compare outputs on topic clarity, evidence retention, and action-item completeness. 2. Formalize a minutes template and the pre-release checklist as part of your meeting close process; require at least one attendee to confirm items labeled "confirmed" before distribution. 3. Sync action items into your task tracker and review them at the next meeting to close the loop.
Closing note: A useful meeting minute should answer four questions next time you meet: What was discussed? What was formally decided? Who committed to what? How will completion be verified? Use those questions as acceptance criteria to reduce follow-up friction.