Meeting Digest
도구: 단계 호출 역할 연산 (
pm.*,email.*,calendar.*,docs.*,files.*,comms.*). 각각은Context/agent-config.md→ Tool Stack 및 해당 어댑터(.claude/adapters/README.md)를 통해 확인합니다. 역할이none으로 설정된 경우 → 해당 단계를 건너뜁니다.
대상 날짜의 모든 회의를 가져오고, 각 회의의 노트나 기록을 찾아 구조화된 요약서를 생성한 후 로컬에 저장합니다. 대상 날짜의 기본값은 오늘입니다. "yesterday"를 전달하면 전날을 처리합니다.
설정
처음에 Context/agent-config.md를 읽으세요. 다음을 사용합니다.
timezone— 모든 날짜 계산에 사용base_directory— 파일 경로 구성 및 멱등성 확인용calendar_exclusions— 건너뛸 회의 제목 패턴 목록- Tool Stack → Meeting notes — 회의 내용을 가져올 위치
4단계에서 프로젝트 및 마일스톤 이름을 인식할 수 있도록 에이전트 설정의 목표 파일을 읽으세요.
지침
모든 단계를 순서대로 실행하세요. 명시적으로 일시 중지하라고 지시하지 않는 한 단계 사이에 확인을 요청하지 마세요.
1단계 — 대상 날짜의 요약되지 않은 모든 회의 가져오기
A단계 — 캘린더: 회의 목록 가져오기
-
사용자의 시간대에 맞춰 대상 날짜를 계산합니다. 기본값 = 오늘; 사용자가 "yesterday"를 전달한 경우 하루를 뺍니다.
-
calendar.events(대상 날짜 시작, 대상 날짜 끝)을 사용자의 시간대로 호출합니다. -
실제 회의만 필터링합니다. 다음 조건에 해당하는 이벤트는 제거합니다.
summary가calendar_exclusions의 패턴과 일치하는 경우- 집중 시간 또는 작업 위치 블록인 경우
attendees목록이 비어 있거나 사용자만 포함된 경우(개인 블록)
-
시간순으로 정렬(가장 오래된 것부터). 이것이 처리할 순서 있는 회의 목록입니다.
B단계 — 멱등성 확인
각 회의에 대해:
- 예상 노트 파일 이름을 생성합니다:
YYYY-MM-DD - [회의 이름].md(캘린더 이벤트summary사용). 이름을 정리합니다:/,\,:및|를-로 바꾸고, 이모지를 제거하며, 반복되는 공백을 축약합니다. [base_directory]/Context/Meeting Notes/에 해당 이름의 파일이 이미 있는지 확인합니다.- 파일이 있고 이미
## Summary섹션이 있는 경우 → 이 회의를 건너뜁니다. 출력: "[회의 이름]의 노트가 이미 존재합니다 — 건너뜁니다." - 파일이 원시 노트로 존재하지만(
## Summary없음) → 해당 내용을 소스로 사용하고 계속 진행합니다. - 파일이 존재하지 않는 경우 → C단계로 진행합니다.
C단계 — 회의 내용 찾기
다음 순서로 소스를 확인하고 내용이 있는 첫 번째 소스를 사용합니다.
- 원시 노트 파일 — B단계 4번의 파일.
- 설정된 소스 — agent-config의 각 항목 → Meeting notes sources 순서대로. 일반적인 예시:
- 캘린더 첨부 파일 — 이벤트에 첨부된 노트 문서 →
files.read를 파일 ID로 호출. "찾을 수 없음"은 사용자와 공유되지 않은 경우이므로 조용히 건너뜁니다. docs.meeting_notes(date)— 제목 또는 시간 창(±30분)으로 일치;docs.read로 읽습니다.
- 캘린더 첨부 파일 — 이벤트에 첨부된 노트 문서 →
- 캘린더 이벤트 설명 — 실제 노트가 포함된 경우에만 사용합니다(단순한 안건이나 비디오 링크가 아닌 경우).
- 사용자에게 질문 — 여전히 내용이 없는 회의를 한 메시지에 나열합니다: "다음 회의에 대한 노트를 찾을 수 없습니다: [목록]. 요약하려는 회의의 노트나 기록을 붙여넣거나, 건너뛰라고 말씀해 주세요."
회의에 여전히 내용이 없는 경우 → "노트 없음"으로 표시하고 건너뜁니다.
D단계 — 보고
모든 회의를 처리한 후 보고합니다.
- 요약된 회의 수
- 건너뛴 회의 수(이유 포함: 이미 존재함 / 노트 없음)
2단계 — 컨텍스트 읽기
노트 내용을 처리하기 전에 다음을 읽습니다.
GOALS.md— 활성 프로젝트와 목표를 이해하기 위해Context/Memory/brain.md— 사용자의 사고 방식, 어휘, 결정과 논의를 구분하는 기준을 이해하기 위해
3단계 — 노트 내용 분석
내용이 있는 각 회의에 대해 네 가지를 추출합니다.
A. 요약 2-3문장. 신호 우선: 회의의 주제와 핵심 결과 또는 변화는 무엇이었는지. 다룬 주제의 목록이 아니라, 하나의 일관된 결과 진술. 사용자의 어조를 사용하세요: 직접적이고, 노력 강조 없이, 결과로 이끕니다.
B. 결정 사항 방향을 바꾸거나, 무언가를 확정했거나, 열린 질문을 종결한 명시적 약속. 실제 결정만 — 제안이나 "아마"는 제외. 형식: 결정된 내용, 결정한 사람(특정 가능한 경우).
C. 액션 아이템 책임자가 명명된 구체적인 다음 단계. 항목별로 다음 논리를 적용합니다.
- 노트에서 특정 인물을 높은 신뢰도로 책임자로 지명한 경우 → 해당 인물에게 할당
- 책임 소재가 모호하거나 공유된 경우 → 사용자에게 할당
- 프로젝트 관리 항목이나 프로젝트는 회의에서 명시적으로 언급된 경우에만 포함합니다(키, 이름 또는 명확한 참조로). 추론하거나 추측하지 마세요. 언급되지 않은 경우 프로젝트 열을 비워 둡니다(
—). - 회의에서 언급된 경우 제안된 기한을 기록하고, 그렇지 않으면 비워 둡니다.
D. 미해결 질문 / 블로커 미해결 질문, 제기된 블로커, 또는 향후 회의로 연기된 주제. 이는 노트 파일에만 기록됩니다.
4단계 — 프로젝트 참조
항목 키나 프로젝트 이름이 회의에서 명시적으로 언급된 경우에만 기록합니다 — 키(예: ENG-123), 이름(예: "온보딩 리뉴얼 마일스톤"), 또는 모호하지 않은 참조로.
회의 컨텍스트에서 프로젝트를 추론하거나, 조회하거나, 추측하지 마세요. 잘못된 프로젝트를 할당하는 것보다 비워 두는 것이 낫습니다.
5단계 — 회의 노트 파일 작성
다음 파일 이름 형식을 사용하여 요약서를 Context/Meeting Notes/에 저장합니다.
YYYY-MM-DD - [회의 이름].md
회의 이름으로 캘린더 이벤트 summary를 사용합니다.
파일 형식:
# [회의 이름]
*[YYYY-MM-DD] | [기간(가능한 경우)] | [참석자(캘린더에서 가능한 경우)]*
## 요약
[신호 우선 2-3문장 요약. 무슨 일이 있었고 무엇이 바뀌었는지.]
## 결정 사항
- [결정 1 — 알려진 경우 결정한 사람]
- [결정 2]
## 액션 아이템
| # | 작업 | 담당자 | 프로젝트 | 기한 |
|---|------|-------|---------|-----|
| 1 | [작업 설명] | [이름 / me] | [프로젝트 이름 (KEY-123) 또는 —] | [날짜 또는 —] |
| 2 | ... | ... | ... | ... |
## 미해결 질문 및 블로커
- [질문 또는 블로커 — 해결되지 않은 사항과 그 중요성]
## 컨텍스트
[회의에서 나온 향후 참고에 유용한 배경, 링크 또는 프레임 정보. 최대 3-5개 항목으로 유지.]
소스가 원시 노트인 경우(B단계 4단계), 해당 노트를 ## 원시 노트 섹션으로 하단에 유지하세요 — 사용자의 노트를 절대 삭제하지 마세요.
저장 전에, Obsidian 그래프 연결을 위해 노트에 [[위키-링크]]를 추가하세요.
- 이름으로 언급된 모든 사람 →
[[이름]] - 모든 항목 키 →
[[KEY-123]] - 노트 간에 반복되는 주요 개념, 프로젝트 및 테마 →
[[개념]] - 의미 있는 언급만 연결하세요 — 모든 단어가 아니라, 코드 블록이나 URL 내부는 제외
사용자에게 확인: "회의 노트가 Context/Meeting Notes/[filename].md에 저장되었습니다."
6단계 — 연속성 유지
저장 후:
- 이 회의의 결정 사항이나 블로커가
Tasks/의 열린 작업과 관련이 있는지 확인하고, 관련이 있으면 인라인으로 기록합니다. GOALS.md에 이미 알려진 블로커로 존재하는 블로커가 제기된 경우 플래그를 지정합니다: "이 블로커([이름])는 [이전 컨텍스트]에서도 제기되었습니다. 시스템적인 문제인지 고려하세요."- 회의가
Context/121s/에 문서가 있는 특정 인물과의 정기 1:1인 경우, 해당 문서에 세션 로그 항목(날짜, 한 줄 요약, 추가된 미해결 루프)을 추가합니다.
회의 노트에는 개인 데이터가 포함되어 있으며 절대 커밋되거나 푸시되지 않습니다.
7단계 — 채팅에 요약 표시
모든 노트를 로컬에 저장한 후, 하루 전체 요약서의 결합된 요약을 하나 표시합니다.
구조: 회의 → 주제 → 각 주제 아래 결정 사항 + 액션 아이템.
📝 **회의 요약 완료 — [YYYY-MM-DD]** | [N]개 요약됨 | [N]개 건너뜀
*[회의 이름]*
[주제 / 목표 또는 마일스톤]
결정 사항
- [결정]
- [결정]
액션 아이템
- [작업] → [담당자] [기한(알려진 경우)]
[주제 2]
결정 사항
- [결정]
액션 아이템
- [작업] → [담당자]
노트가 `Context/Meeting Notes/`에 저장되었습니다.
그룹화 규칙:
- 최상위: 회의 이름
- 두 번째 수준: 해당 회의에서 논의된 주제, 목표 또는 마일스톤 — 일반 이름 사용, 절대 이슈 키만 사용하지 않음
- 세 번째 수준: 각 주제 아래 결정 사항 및 액션 아이템을 레이블이 있는 하위 섹션으로 표시
- 주제에 결정 사항이 없으면 결정 사항 하위 섹션을 생략합니다. 액션 아이템이 없으면 액션 아이템 하위 섹션을 생략합니다.
- 회의에 주제가 하나만 있어도 주제 이름을 표시합니다 — 축약하지 않습니다.
- 채팅 요약에서 액션 아이템의 프로젝트 열은 생략합니다 — 노트 파일에만 포함됩니다.
8단계 — 결정 로그 업데이트 제안
이 단계는 요약된 모든 회의에서 최소 하나의 결정 사항이 추출된 경우에만 실행됩니다.
한 번, 단일 메시지로 질문합니다.
"이 결정 사항 중 일부를 PRD의 결정 로그에 기록하시겠습니까?
오늘의 결정 사항:
[회의 이름] [주제] 1. [결정] 2. [결정]
예인 경우, 어떤 문서(로컬 파일:
Context/Document Hub/또는 문서 도구의 페이지)와 추가할 결정 번호를 알려주세요."
모든 회의에 걸쳐 결정 사항에 순차적으로 번호를 매겨 사용자가 번호로 참조할 수 있도록 합니다.
사용자의 응답을 기다립니다.
- 아니오 / 건너뛰기인 경우: 스킬을 종료합니다.
- 예인 경우: 사용자가 지정한 각 문서에 대해 아래 단계를 진행합니다.
각 제공된 문서에 대해:
A. 문서 가져오기
- 로컬 파일 → 읽습니다.
- 문서 도구 페이지 →
docs.read.
B. 결정 로그 찾기
제목에 "Decision Log", "Decisions Log" 또는 "Decisions"가 포함된 섹션을 검색합니다(대소문자 구분 없음).
- 결정 로그 섹션에 테이블이 있는 경우: 새 행을 추가합니다.
- 결정 로그 섹션이 있지만 테이블이 없는 경우: 제목 바로 아래에 테이블을 삽입합니다.
- 결정 로그 섹션이 없는 경우: 문서 하단에 새
## 결정 로그섹션과 테이블을 삽입합니다.
C. 행 생성
사용자가 선택한 각 결정에 대해 하나의 테이블 행을 생성합니다.
| [YYYY-MM-DD] | [결정 텍스트] | [상태] |
- 날짜: 회의 날짜.
- 결정: 요약서의 정확한 텍스트 — 의역하지 마세요.
- 상태: 명시적이고 최종적인 경우
결정됨. 텍스트에 "TBD", "확인 예정", "보류 중", "대기 중"이 포함되거나 해결되지 않은 것으로 표시된 경우보류 중.
테이블이 아직 존재하지 않는 경우 다음 헤더 행을 먼저 생성합니다.
| 날짜 | 결정 | 비고/상태 |
|------|----------|--------------|
D. 미리보기 후 업데이트
추가될 행을 표시합니다. 로컬 파일의 경우 해당 행을 씁니다. 문서 도구 페이지의 경우 사용자의 명시적 확인을 기다린 후 docs.update(ref, "결정 로그", rows) — 해당 섹션만 변경합니다.
E. 확인
"[문서 제목]의 결정 로그가 업데이트되었습니다 — [N]개의 결정 사항이 추가되었습니다."
엣지 케이스
- 결정 사항을 찾을 수 없음: "결정된 사항 없음 — 논의/업데이트 회의입니다."라고 작성합니다. 결정 사항을 임의로 만들지 마세요.
- 액션 아이템을 찾을 수 없음: "액션 아이템 없음."이라고 작성합니다.
- 회의가 스탠드업 또는 5분 미만인 경우: 요약서를 계속 생성하지만 요약을 한 문장으로 유지합니다.
- 동일한 이벤트와 일치하는 여러 노트: 이벤트 시작 시간에 가장 가까운 노트를 사용합니다.
- 소스를 사용할 수 없는 경우: 조용히 건너뛰고 C단계에서 다음 소스로 넘어갑니다.
- 문서 페이지를 찾을 수 없는 경우(8단계): 오류를 보고하고 사용자에게 URL을 다시 확인하도록 요청한 후 재시도를 제안합니다.
- 결정 로그 섹션이 모호한 경우(8단계): 여러 제목이 일치할 수 있는 경우(예: "주요 결정" 및 "결정 로그"), 둘 다 표시하고 어느 쪽에 추가할지 질문합니다.
- 중복 결정(8단계): 삽입 전에 기존 행을 스캔합니다. 동일한 결정 텍스트가 이미 있는 경우 건너뛰고 건너뛰었음을 기록합니다.