meeting-notes git:20260708.fbacaf6A

Immutable. This exact content is served forever at /api/v1/blob/65c38e1b6f3bc3d5.

---
name: meeting-notes
description: Use when turning raw meeting notes, a transcript, or an ASR/recording dump into a structured record — separating discussion / decisions / action items, extracting owned action items with verbatim grounding, mapping related docs and tickets, and recommending a next step per action item. Triggers include 회의록 정리, 회의 정리해줘, 이 회의록에서 액션아이템 뽑아줘, 미팅 노트 정리, 회의 녹취록 정리, transcript to action items, meeting notes to action items, summarize this meeting, standup/retro/decision meeting notes.
---

# Meeting-Notes — Raw Meeting to Structured Record Pipeline

A synthesis pipeline that turns a raw meeting transcript (ASR dump, notes, recording) into ONE structured markdown report: a type-aware summary that separates discussion / decisions / action items, action items extracted under a validity gate and grounded in verbatim quotes, related artifacts discovered live and mapped to specific items, and a per-action next-step recommendation. It PROPOSES; it never executes an action item.

## Foundational Principle

**A meeting record is a record of what was DECIDED and what will be DONE — not a transcript of what was said.** Every stage separates 논의 (discussion — context that was exchanged) / 결정 (decision — what the conversation settled) / 액션아이템 (action item — a concrete task derived from a decision). When the transcript does not support a claim, the record says so with an explicit marker (`[미배정]`, `[기한 미정]`, `confidence: low`) rather than inventing it.

**Violating the letter of the anti-fabrication rules is violating the spirit.** A fabricated owner, an ungrounded action item, or a hedged commitment promoted to firm is a pipeline FAILURE, not a helpful extra — see Inline Gates.

---

## Pipeline Overview

The pipeline runs in seven sequential stages:

```
detect type
  → summarize (type-routed)      (READ references/type-schemas.md at this stage)
    → extract action items       (2-gate + owner/due recovery — READ references/extract-actionitems.md)
      → validate (3 layers)      (grounding / completeness / abstention — inline gate, detail in the same reference)
        → discover + map         (live artifacts mapped to specific items — READ references/gather-crosslink.md)
          → recommend next step  (per action item, from the LIVE available-skills list)
            → render             (write ONE markdown file to $OMT_DIR/meeting-notes/{slug}.md)
```

Each stage is described below. The 3-layer validation (Stage 4) is a hard inline gate — a trust boundary against hallucination that is never simplified away. See Inline Gates.

**Single-meeting scope**: one meeting per run. Cross-meeting action-item merge/dedup is out of scope (an unsolved problem — do not attempt owner+task similarity merging across meetings).

**Tool-agnostic principle** (stated once): the judgment body names abstract source TYPES (collaboration-docs, PM, messenger) and abstract write-steps only. Concrete MCP/tool identifiers (`mcp__notion__…`, `mcp__linear__…`, `mcp__slack__…`) are never named in this skill — each abstract type is bound to whatever MCP is wired at runtime (Stage 5), and the report file is written at Stage 7.

---

## Stage 1: Detect Meeting Type

Detect the meeting type from content, keyed to the meeting's **native output** (the deliverable this meeting exists to produce). The six types and what each yields:

| Type | Native output | Keep | Discard by default |
|---|---|---|---|
| 스탠드업 (standup) | status + blockers | blockers, today's commitments | status narration, chatter |
| 의사결정·기획 (decision / planning) | the confirmed decision | decision + rationale + **rejected alternatives** | the debate transcript |
| 회고 (retrospective) | 1–3 owned action items | action items | the feedback grid (after synthesis) |
| 1:1 | (rarely shared) | private follow-ups | shareability itself |
| 브레인스토밍 (brainstorming) | the full idea inventory | every idea | filtering (convergence is separate) |
| 인터뷰·리서치 (interview / research) | verbatim quotes | source quotes, observations | paraphrased summary |

**Detection is by native output, not keyword.** Ask: what single deliverable is this meeting producing? Route the summary schema accordingly (Stage 2).

**Confidence gate**: when the content is mixed or the native output is ambiguous (e.g. a planning meeting that drifts into brainstorming), do NOT silently pick. Ask the user ONE confirmation question naming the two most likely types, then proceed with the confirmed type. A clear single type needs no confirmation.

**Fits none of the six?** A meeting whose native output matches none of the six (e.g. an all-hands announcement, a kickoff) routes to the general fallback schema (references/type-schemas.md §3.7) with a `general` type slug — this is not the ambiguous-between-two case, so no confirmation is needed.

---

## Stage 2: Summarize (Type-Routed)

Read `references/type-schemas.md` now (using the Read tool with path `references/type-schemas.md`). It contains the common report skeleton (dual layout: topic chapters + flat lists), the per-type schema overrides for the core three (decision/planning with DACI, retro, standup), the brainstorming reversal (Gate 2 OFF), and the general fallback schema. Follow it in full.

Apply the routed schema to produce the summary sections. Enforce the 3-way split: 논의 / 결정 / 액션아이템 never conflate. A decision-meeting summary preserves rejected/deferred alternatives with their reasons (the most-often-dropped, most-valuable field). A brainstorming summary preserves every idea and clusters them — it does NOT force action items.

---

## Stage 3: Extract Action Items

Read `references/extract-actionitems.md` now (using the Read tool with path `references/extract-actionitems.md`). It contains the 2-gate extraction procedure (Gate 1 recall signals → Gate 2 validity filter), the context-near-utterance owner/due recovery rule, and the 3-layer validation detail used by Stage 4. Follow it in full.

Extraction runs Gate 1 (catch every commitment signal — recall first) then Gate 2 (keep only real action items — the 3-part test, verb-form filter, independent-completion, uptake/agreement gate, hedge filter). Recover a missing owner or due date ONLY from adjacent turns and diarized speaker labels (context-near-utterance) — never from an external system.

---

## Stage 4: Validate (3 Layers) — Trust Boundary

The three validation layers are a hard gate. They are detailed in `references/extract-actionitems.md` (already loaded in Stage 3) and enforced here and in Inline Gates:

1. **Grounding** — every action item cites a verbatim transcript quote (`근거: "..."`). An item that cannot cite one is DROPPED, not emitted.
2. **Completeness** — the three fields (owner / task / due) are present or explicitly marked `[미배정]` / `[기한 미정]`. No blank field is left silent, and no field is fabricated.
3. **Abstention** — a hedged, implicit, or unclear-owner item is marked `confidence: low` and routed to human review, not promoted to a firm action item.

This layer is never skipped and never softened. It is the difference between a record and a hallucination.

---

## Stage 5: Discover + Map

Read `references/gather-crosslink.md` now (using the Read tool with path `references/gather-crosslink.md`). It contains the gather bound, the gather-then-judge ordering, source-unreachable graceful-skip, the forbidden curation anti-patterns, and the `## 관련 자료` reference format. Follow it in full.

Two adaptations for the meeting domain (stated in that file): the **search seed** is the meeting's decisions, action items, and topics (not a single issue's requirement); the **link target** is each individual action item / decision (each mapped artifact attaches to a specific item, not to one issue).

Discovery is bounded and curated. Zero related artifacts is a valid outcome. An unwired source is skipped with a one-line note. Never emit a numeric relevance-score table or ranking.

---

## Stage 6: Recommend Next Step

For each extracted action item, recommend how to make progress on it, drawn from the **live available-skills list in this session** — the skills and agents actually offered to you right now, not a hardcoded catalog.

- Scan the live list, match the action item to a skill/agent by its stated trigger, and emit a prose bullet: a one-line plan + a literal `Skill(skill: "...")` (or agent) hint + a one-line rationale for the match.
- **No fit? Say so honestly**: label the item a manual / external action (e.g. "manual: read the vendor doc", "external: waiting on another team"). Never invent a skill name to fill the slot.
- **Decision follow-ups are optional**: a decision may get a light record/notify follow-up bullet, but a decision is never force-fit with an execution tool. If nothing natural fits a decision, leave it with no recommendation.

This mirrors the live-list, no-hardcoded-catalog idiom used by `goal` and `deep-interview` Phase 5.

---

## Stage 7: Render

Assemble the summary (Stage 2), validated action items (Stages 3–4), the mapping (Stage 5), and the recommendations (Stage 6) into ONE markdown report, and write it to a file.

**Path**: `$OMT_DIR/meeting-notes/{date}-{type}-{topic}.md`

- **slug** = `{date}-{type}-{topic}` in kebab-case. `date` = `YYYYMMDD`; `type` = the detected type in a short English slug (`decision`, `retro`, `standup`, `brainstorming`, `interview`, `1on1`, or `general` for a meeting that took the §3.7 general fallback); `topic` = a 2–4 word kebab summary of the subject (e.g. `20260708-decision-payment-installment`).
- **Collision**: if the target path already exists, append `-2` (`-3`, …) to the slug.
- **Missing meeting metadata**: parse date/topic from the transcript; if absent, do NOT fabricate. Mark the report body `[날짜 미상]` / `[미상]`. For the slug's date specifically, ask the user ONCE for the meeting date; if they cannot supply it, use `nodate` in the slug and `[날짜 미상]` in the body. Likewise, if no subject can be derived, use `notopic` in the slug and `[미상]` in the body — never fabricate a topic to fill the slug.

The report body is Korean-first (the team's working language); this skill's own instructions stay English. Output markdown only — no HTML render.

**Proposal-only**: the report ends here. Creating issues, pushing to a docs tool, or notifying anyone is a separate, user-approved step this skill never performs.

---

## Inline Gates

These gates apply before Stage 7 renders. Failing any gate blocks the render of the offending item — fix or drop it, then continue.

### Anti-Fabrication Gate (the trust boundary)

The 3-layer validation (Stage 4) exists because a capable agent, told to "summarize this meeting and extract action items", will over-reach to be helpful: it fills owners it doesn't know, promotes tentative talk to firm tasks, and presents outside research as meeting facts. Each of those is a fabrication.

**Owner and due recovery is bounded to the transcript.** Recover a missing owner/due from adjacent turns + diarized speaker labels ONLY. If the transcript does not name who owns an item, it is `[미배정]` — full stop.

**Rationalization table — every excuse below means "mark the honest marker, do not fabricate":**

| Rationalization | Reality |
|---|---|
| "The transcript doesn't say who, but the Linear ticket for this is assigned to X, so the owner is X" | The mapping stage (Stage 5) finds related artifacts; it does NOT assign owners. Owner identity comes from the transcript only. Unknown → `[미배정]`. |
| "The diarization label is generic ('Developer'), but I can guess the real name from Slack" | A generic speaker label is the owner as-recorded. Do not resolve it to a real identity via external correlation. Keep the label or mark `[미배정]`; note the ambiguity. |
| "This commitment is hedged ('아마 …해야 할 것 같아요'), but it's clearly the intent, so I'll list it as a firm action" | Hedged = not yet committed. Mark `confidence: low` → human review. Promoting it is the exact failure this gate blocks. |
| "I found the answer to the meeting's open question in an external doc — I'll present it as a resolved decision" | The record captures what THIS meeting decided. An external finding may appear in `## 관련 자료` as a mapped artifact, never as a decision the meeting did not make. |
| "No verbatim quote fits this item, but it's obviously implied" | No verbatim quote → drop the item. "Obviously implied" is the hallucination boundary. |
| "A due date wasn't stated, but 'internal' urgency suggests end of week" | Unstated due → `[기한 미정]`. Inferred urgency is not a due date. |

### Red Flags — STOP, you are fabricating

- You are writing an owner name that never appears in the transcript.
- You are resolving a generic speaker label ("Developer") to a real person via Linear/Slack/calendar.
- You are listing a hedged or tentative commitment as a firm action item without `confidence: low`.
- An action item has no `근거: "..."` verbatim quote.
- The mapping stage's external findings are appearing as decisions or action items the meeting did not produce.

**All of these mean: mark the honest marker (`[미배정]` / `[기한 미정]` / `confidence: low`) or drop the item. The transcript is the sole source of what the meeting decided and who owns what.**

### Type-Fit Gate

- A brainstorming transcript with Gate 2 forced ON (idea inventory squeezed into action items) is a FAILURE — brainstorming keeps every idea and forces no action items.
- A decision meeting rendered without its rejected/deferred alternatives is a FAILURE — that field is the most valuable and the most often dropped.

---

## Reference Files

- `references/type-schemas.md`: the six meeting types and native-output detection, the common report skeleton (dual layout), the per-type schema overrides for the core three (decision/planning DACI, retro, standup), the brainstorming Gate-2-OFF reversal, the interview/1:1 notes, and the general fallback schema. Read at Stage 2.
- `references/extract-actionitems.md`: the 2-gate extraction procedure (Gate 1 recall signals, Gate 2 validity filter), the context-near-utterance owner/due recovery rule, the action-item render contract, and the 3-layer validation detail. Read at Stage 3 and enforced at Stage 4.
- `references/gather-crosslink.md`: the gather bound (per-source cap, recency window, logs strict bound), gather-then-judge ordering, source-unreachable graceful-skip, curation rules with forbidden anti-patterns (no relevance-score table / numeric ranking / typed dependency graph), and the `## 관련 자료` reference format with per-entry justification — adapted for the meeting domain (seed = decisions/actions/topics; target = each action item/decision). Read at Stage 5.