Meeting Minutes Writer

Meeting Minutes Writer

Overview

Transform raw meeting content (transcripts, notes, recordings transcribed elsewhere) into concise, scannable meeting minutes that an executive can absorb in three minutes. After producing a draft, this skill runs a structured self-review loop (up to 3 passes) to detect and fix contradictions, missing action items, speaker-name errors, and date/day-of-week mistakes. Completion is only reported when a pass returns zero findings or three passes have been exhausted.

When to Use

Trigger this skill when the user:

• Provides a meeting transcript and asks for "議事録" / "meeting minutes" / "summary"
• Asks to "format / clean up / structure" meeting notes
• Provides a <<Transcript>> block, raw chat log, or recording transcript
• Wants action items and decisions extracted from a discussion

Languages supported: Japanese and English are both first-class. The skill matches the source language by default — Japanese transcript → Japanese minutes, English transcript → English minutes. See the Language Handling section below for the full policy and mixed-language behavior.

When NOT to Use

• Pure transcript cleanup with no structuring needed → just edit text directly
• Reviewing existing minutes only (no generation) → use meeting-minutes-reviewer
• Generating an agenda or pre-meeting brief → use meeting-asset-preparer
• Transcribing video/audio first → use video2minutes (it can call this skill afterwards)

Core Workflow

This skill runs in two phases: Generation, then a Self-Review Loop. Both phases are mandatory.

Phase 1 — Generate Draft (ultrathink)

Use ultrathink mode to analyze the source material thoroughly before writing.

Steps:

1. Scan metadata — meeting name, date, attendees. If absent, infer from content and mark * To be confirmed.
2. Identify speakers — extract a definitive speaker list with roles where derivable.
3. Map discussion threads to topics. Lengthy debates collapse to 2-3 key points.
4. Extract commitments — every "I'll do X", "we should check Y", "let's investigate Z" becomes an action item.
5. Synthesize decisions — explicit consensus or directives become entries under "Decisions Made".
6. Render the draft using the format in references/output_format.md.

Save the draft to a working file (e.g. meeting_minutes_draft.md) so the review loop can edit and re-read it.

Phase 2 — Self-Review Loop (up to 3 iterations)

After producing the draft, run the review loop before reporting completion. Each iteration produces a Findings Report; if findings are non-empty, fix the draft and re-review. Stop when a clean pass occurs OR 3 iterations have run.

iteration = 1
while iteration <= 3:
    findings = run_review(draft)
    if findings.is_empty():
        break  # quality gate passed
    apply_fixes(draft, findings)
    iteration += 1

For each iteration, run the 5 Mandatory Checks below in order. See references/self_review_checklist.md for full criteria and assets/findings_report_template.md for the report layout.

The 5 Mandatory Checks

1. Internal Contradictions — claims that conflict with each other (e.g. "Alice will lead" in §3 but "Bob will lead" in §5; deadline "Aug 20" in action table but "Aug 22" in discussion).
2. Consistency / Coherence — decisions reflect discussion; action items trace back to a stated commitment; numbers, dollar amounts, and counts match across sections.
3. Action Item Omissions — every "will do / should / need to / let's / TODO / follow up" in the source has a corresponding row in the Action Items table; ownership and due date are not silently dropped.
4. Speaker-Name Errors — names spelled consistently with the source (no "Tanaka" → "Tanaka-san" → "田中さん" inconsistency, no swapped first/last names, no attribution drift).
5. Date / Day-of-Week Errors — every concrete date is verified to match its day-of-week using the verification helper (see below). Time-zone conversions (ET↔JST etc.) are also checked.

Date verification — MANDATORY tool use, not memory:

python3 -c "import calendar, datetime; d=datetime.date(YYYY, MM, DD); print(d.strftime('%Y-%m-%d %A'))"

For ET↔JST (or any IANA timezone) conversions — including correct DST handling around the boundaries — use zoneinfo.ZoneInfo with the actual meeting datetime, never a hard-coded offset:

# Convert a specific ET datetime to JST (DST-aware)
python3 -c "
from datetime import datetime
from zoneinfo import ZoneInfo
et = datetime(2026, 3, 8, 9, 30, tzinfo=ZoneInfo('America/New_York'))  # the actual meeting datetime
jst = et.astimezone(ZoneInfo('Asia/Tokyo'))
print(f'{et:%Y-%m-%d %H:%M %Z} = {jst:%Y-%m-%d %H:%M %Z}')
"

Notes:

• Always pass the real meeting date. The DST boundary in the US (2nd Sun of Mar / 1st Sun of Nov) means a fixed +13h/+14h offset is wrong for meetings near the boundary.
• For other timezones use the IANA name: Europe/London, Asia/Singapore, America/Los_Angeles, etc.
• zoneinfo is in the Python 3.9+ standard library; no install required.
• For a quick sanity check on offset only (without DST awareness), the legacy form python3 -c "et=14; off=14; jst=(et+off)%24" may be used as a rough estimate, but the zoneinfo form above is REQUIRED whenever the meeting date crosses or sits near a DST boundary.

Findings format — for each finding record:

• Severity (HIGH blocks completion / MEDIUM should fix / LOW style)
• Location (section + line range or table row)
• Issue (what's wrong)
• Evidence (quote from source if available)
• Suggested fix

Use the structure in assets/findings_report_template.md.

Completion Report

Only report completion when one of these terminates the loop:

• A review iteration returns zero findings → clean pass
• Three iterations have run

The completion report MUST include:

1. Path to the final minutes file
2. Number of review iterations run
3. Findings fixed per iteration (count + brief summary)
4. Any HIGH-severity findings still open after iteration 3 (explicitly flagged)
5. List of items the reader should manually verify (anything tagged * To be confirmed)

If iteration 3 ends with HIGH-severity findings still open, do not silently mark the work as done — surface those open items prominently in the report.

Output Format

The minutes follow the canonical structure below. Two language-specific templates ship with the skill — pick the one matching the source language:

• English source → assets/minutes_template_en.md
• Japanese source → assets/minutes_template_ja.md

English structure

### 1. Meeting Information
- **Meeting Name**: ...
- **Date**: YYYY/MM/DD (Day of Week)
- **Attendees**: ...

### 2. Action Items
| No. | Action Item | Owner | Priority | Due Date | Notes |
|-----|-------------|-------|----------|----------|-------|

### 3. Meeting Details
#### Decisions Made
#### Key Topics and Discussion Points
#### Notes for Future Meetings / Other

Japanese structure (日本語構造)

### 1. 会議情報
- **会議名**: ...
- **開催日**: YYYY/MM/DD（曜日）
- **出席者**: ...

### 2. アクションアイテム
| No. | アクション | 担当 | 優先度 | 期日 | 備考 |
|-----|-----------|------|--------|------|------|

### 3. 会議内容
#### 決定事項
#### 主要トピック・議論内容
#### 次回以降への持ち越し・その他

Priority legend (both languages): 🔴 High (blocking / クリティカル) / 🟡 Medium (should do / 重要) / 🟢 Low (nice to have / あれば良い).

See references/output_format.md for full formatting rules, inference rules, and ambiguity handling.

Language Handling

Both Japanese and English are supported as first-class output languages. The skill matches the source language by default.

Detection rules

1. If the source has a clear majority language (>70% characters), use that language for the entire output (minutes + findings report + completion report).
2. If the source is mixed (e.g. Japanese discussion with English technical terms, or bilingual cross-regional meeting):
   • Use the language with more substantive content for the section headings and connective text.
   • Preserve technical terms, product names, quoted statements, and proper nouns in their original form (do not translate "API" → "API（アプリケーション・プログラミング・インタフェース）" or "田中さん" → "Mr. Tanaka").
3. If the user explicitly requests an output language ("英語で作って" / "in Japanese please"), follow the explicit request and override auto-detection.

What the language choice controls

• Section headings (Meeting Information vs. 会議情報, etc.) — pick the matching template
• Action verb conventions in action items
• Ambiguity markers — * To be confirmed (EN) / * 要確認 (JA)
• Findings Report — use the matching half of assets/findings_report_template.md
• Completion Report wording

What the language choice does NOT control

• Names of people, products, companies — always preserve verbatim from source
• Direct quotes — keep the original language; do not translate
• Date format — always YYYY/MM/DD (Day of Week) numerically; "(Mon)" or "（月）" depending on output language
• Time-zone abbreviations (JST, ET, UTC) — keep ASCII

Self-review in matching language

The 5 Mandatory Checks must be run with the source-language patterns active:

• Action-item phrases (JA): 「やります」「対応します」「確認します」「調べます」「フォローします」「持ち帰り」「宿題」「TODO」
• Action-item phrases (EN): "I'll do", "we should", "let's check", "need to investigate", "follow up", "TODO"
• Speaker-name errors: be especially careful with JA honorifics (「さん」「様」「課長」) and JA↔Romaji inconsistency (「田中さん」 vs "Tanaka-san" vs "Tanaka")
• Date format errors: also check JA-specific formats like "令和○年" / "○月○日" / "来週火曜" before normalizing

Examples

Example 1: Standard transcript

User: "Here's today's product planning transcript: <>...<>"

Skill behavior:

1. Generate draft following the 6-step generation workflow.
2. Iteration 1 review finds 2 issues: (a) "Alice owns DB migration" in action table but discussion shows Bob volunteered; (b) "next Tuesday" rendered as 8/13 but 8/13 is Wednesday.
3. Fix both, run iteration 2 → 0 findings → clean pass.
4. Report: 2 iterations, 2 findings fixed, file saved at ./meeting_minutes_2026-04-30.md.

Example 2: Sparse notes

User: "Quick notes from standup, please clean up"

Skill behavior:

1. Generate draft. Mark missing fields * To be confirmed.
2. Iteration 1 finds 1 omission (a "follow up with vendor next week" line wasn't captured as an action) → fix.
3. Iteration 2 → 0 findings.
4. Report: 2 iterations, 1 finding fixed, lists all * To be confirmed items for the user to fill in.

Example 3: Loop exhausts

User: Provides a long, contradictory transcript.

Skill behavior:

1. Iteration 1 → 5 findings; iteration 2 → 2 remaining + 1 new; iteration 3 → 1 HIGH still open (a date that the source itself contradicts).
2. Report: 3 iterations run, 6 findings fixed total, 1 HIGH finding remains (transcript itself is ambiguous about whether the launch is 2026-05-15 Friday or 2026-05-16 Saturday — flagged for user resolution).

Example 4: 日本語トランスクリプト

ユーザー: 「今日の定例の文字起こしです、議事録にしてください: <>...<>」

スキルの挙動:

1. ソース言語が日本語と判定 → assets/minutes_template_ja.md を採用
2. 日本語で議事録ドラフトを生成（「会議情報」「アクションアイテム」「決定事項」など日本語見出し）
3. 第1反復のレビューで3件検出: (a)「田中さん」と「田中課長」の表記揺れ、(b) 山田氏が「来週金曜までに」と発言した箇所が期日空欄、(c) 「5/15(金)」と書いてあるが実際は木曜
4. 修正後、第2反復で0件 → クリーンパス
5. 完了報告（日本語）: 反復2回、修正3件、出力ファイル 議事録_2026-04-30.md、要手動確認項目なし

Example 5: バイリンガル会議

User: "Cross-regional standup, mixed JP/EN. Please write minutes."

Skill behavior:

1. Detect majority language (e.g. 60% English) → use English template
2. Preserve Japanese names verbatim ("田中さん", not "Mr. Tanaka") and English technical terms verbatim
3. Quoted statements kept in original language: > "じゃあ来週まで" / > "Let's verify by EOW"
4. Run review loop in English; speaker-name check pays special attention to JP honorifics
5. Completion report in English; flag any * To be confirmed items including any JP-specific terms the user should sanity-check

Resources

references/

• output_format.md — full minutes formatting spec, inference rules, ambiguity handling
• self_review_checklist.md — detailed criteria for each of the 5 mandatory checks

assets/

• minutes_template_en.md — blank meeting minutes template (English)
• minutes_template_ja.md — 議事録テンプレート（日本語）
• findings_report_template.md — findings report template (bilingual, EN + JA layouts)

Best Practices

• Never skip the review loop. Even short minutes need at least one self-review pass before completion is reported.
• Always verify dates with python3 -c ... — never guess day-of-week from memory; LLMs are unreliable here.
• Keep findings actionable. Every finding must include a suggested fix, not just "this is wrong."
• Preserve user-provided names verbatim — if the source writes "田中さん", do not normalize to "Tanaka" in the minutes.
• Quote evidence from the source when raising a finding so the fix is auditable.
• Use * To be confirmed markers liberally for inferred content; surface them in the completion report.
• Don't paraphrase decisions — record decisions in language close to what was actually agreed, to preserve auditability.