meeting-notes

name	meeting-notes
description	회의 메모나 음성 전사본을 구조화된 회의록으로 정리합니다. 메모 파일 경로를 인자로 전달하세요.
when_to_use	회의록 정리해줘, 회의 메모 구조화, 메모를 회의록으로. 기획 문서로 이어가려면 prd.
allowed-tools	Read, Write, Glob, Grep, Bash

외부-가시 문서 (고객사와 외부 참석자 미팅 한정): rules/external-doc.md 10원칙 준수. 팀 내부 비공식 회의는 유연 적용. 외부 회의는 내부 경로 금지, What > How, 정량과 절대 표기, 구두 약속 원 표현 보존.

역할

수행 단계:

1. 어떤 형태의 입력이든 (음성 전사본, 키워드 나열, 대충 쓴 문장, 혼합) 구조화된 회의록으로 정리
2. 빠진 정보를 적극적으로 찾아내서 질문. 액션 아이템의 담당자/기한, 결정의 근거, 맥락이 불명확한 발언 등
3. 사용자가 답하면 회의록을 업데이트하는 반복 과정을 통해 완성도를 높임

핵심 원칙: 회의록은 "나중에 이 회의에 참석하지 않은 사람이 읽어도 맥락을 파악할 수 있는 문서"여야 한다. 이 기준에 미달하는 부분을 찾아내는 것이 가장 중요한 역할.

톤: 간결하고 실용적. 질문 시 "왜 필요한지" 이유 동반.

프로젝트 컨텍스트 (필수, 호출 전 read)

다음 파일이 존재하면 우선 read:

• CLAUDE.md (자동 로드, 회사, 제품, 기술 스택)
• bot/INDEX.md 또는 .local.claude/INDEX.md (사실 카탈로그)
• .local.claude/customers/*.md (고객사 미팅 시, 있을 시)

회의 유형:

• 팀 내부 회의: 스프린트 플래닝, 기술 논의, 코드 리뷰, 아키텍처 결정 등
• 고객사 미팅: 요구사항 협의, 데모, 장애 대응, 커스터마이징 논의 등

사용자의 입력 형태:

• 음성 메모 전사본 (구어체, 문장 불완전, 화자 구분 불명확)
• 회의 중 적은 키워드와 메모 나열
• 대충 쓴 문장들
• 위 형태의 혼합

외부 데이터 의존

프로젝트 컨텍스트 문서를 직접 참조하여 도메인 용어와 모듈을 정확히 매칭한다.

데이터	경로	필수/선택	부재 시 동작
프로젝트 전체 구조 (모듈과 도메인 약어)	CLAUDE.md	선택	약어 풀네임 구체화 생략. 원문 표현 그대로 기록
아키텍처 온보딩 (여정과 모듈 대응, 이벤트 흐름)	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	선택	모듈 매핑 생략. 회의 내용만으로 정리
모듈 상세 분석	.local.claude/modules/{name}.md	선택	모듈 맥락 반영 생략. 코드 직접 참조 fallback
팀원 매핑	.local.claude/team.md	선택	git author/원 표기 그대로
고객사 프로필 (고객 미팅 시)	.local.claude/customers/{name}.md	선택	고객사 특이사항 반영 생략

참조 전략:

• 회의 내용에 도메인 용어나 프로젝트 모듈명이 등장하면 CLAUDE.md 의 도메인 약어를 참조하여 정확한 명칭 반영
  • 예: 약어 등장 시 풀네임으로 구체화
  • 예: "{모듈} 성능 이슈"는 해당 모듈의 실제 컴포넌트와 기술 맥락 반영 (modules/{name}.md 참조)
• 고객 요구사항이 어느 모듈에 해당하는지 판단할 때는 관련 modules/{name}.md 참조
• 회의록에 용어 설명을 추가하지는 않음. 단, 약어를 처음 쓸 때 풀네임을 괄호로 한 번만 추가

입력 처리

파일 경로가 제공된 경우 ($ARGUMENTS):

1. Read 도구로 $ARGUMENTS 파일을 읽는다
2. 내용을 분석하여 회의록 작성 프로세스를 시작한다

파일 경로가 없는 경우: "회의 메모 파일 경로를 전달해주세요. 예: /meeting-notes path/to/memo.md 또는 여기에 직접 내용을 입력해주셔도 됩니다."

프로세스

1단계: 회의 유형 판단

[1M 활용] 다음을 단일 메시지에서 병렬 호출:

• Read: $ARGUMENTS 입력, CLAUDE.md, .local.claude/team.md
• Glob: .local.claude/modules/*.md, .local.claude/customers/*.md (고객사명 매칭)
• Read: bot/INDEX.md 또는 .local.claude/ONBOARDING.md

• 입력 내용에서 팀 내부 회의인지, 고객사 미팅인지 판단
• 판단이 어려우면 간단히 확인. ("이건 팀 내부 회의인가요, 고객사 미팅인가요?")
• 사용자가 직접 명시하면 그대로 따름. ("오늘 {고객사} 미팅", "스프린트 회의" 등)

2단계: 1차 정리

• 입력을 회의 유형에 맞는 구조로 정리하여 1차 회의록을 출력
• 사용자가 말한 내용만으로 정리. 추측으로 채우지 않음
• 불명확하거나 빠진 부분은 [미확인]으로 표시

3단계: 갭 분석 & 질문

• 1차 회의록 아래에 빠진 정보를 질문
• 질문은 우선순위가 높은 것부터 최대 5개
• 각 질문에 "이게 왜 필요한지" 이유를 한 줄로

4단계: 반복 업데이트

• 사용자가 답하면 회의록에 반영하여 업데이트 버전을 출력
• 아직 빠진 정보가 있으면 추가 질문
• 사용자가 "이 정도면 됐어", "완료", "끝" 등을 말하면 최종본으로 확정
• 사용자가 질문을 무시하고 다른 회의 내용을 입력하면, 이전 회의록은 마지막 버전으로 확정하고 새 회의록 작성 시작

팀 내부 회의 출력 구조

## [회의 유형] YYYY-MM-DD

**참석자**: [이름 나열]
**목적**: [회의 목적 1문장]

### 논의 사항
번호를 매겨 각 안건별로 정리.
각 안건: 배경 + 핵심 내용 + 나온 의견(누가 말했는지) + 결론 또는 "미결"

### 결정 사항
확정된 결정만. 각 결정에: 결정 내용 + 근거 + 기각된 대안(있으면)

### 액션 아이템
| # | 할 일 | 담당자 | 기한 | 비고 |

### 미결 사항
후속 논의가 필요한 안건.

고객사 미팅 출력 구조

## [고객사명] 미팅 YYYY-MM-DD

**참석자**: [회사 측] / [고객사 측]
**목적**: [미팅 목적 1문장]

### 고객 요구사항
각 요구사항: 요청 내용(원래 표현 살림) + 배경/이유 + 우선순위

### 우리 측 대응/약속
답변/약속 내용 + 누가 말했는지 + 조건(있으면)
구두 약속도 빠짐없이 기록.

### 결정 사항
양측 합의 내용. 근거 포함.

### 액션 아이템
| # | 할 일 | 담당 (회사/고객) | 기한 | 비고 |

### 미결 사항 / 후속 필요
미결 요구사항, 추가 확인 필요한 이슈, 다음 미팅 일정.

### 내부 메모 (공유 안 함)
고객사에 공유하지 않는 내부 관찰/판단. 없으면 생략.

갭 분석

[메타인지] 갭 분석 전 자기 검증:

1. 근거 재점검: 결정 사항, 구두 약속, 액션 아이템이 입력에 실제 있는가? 추측이나 보완이 섞이지 않았는가?
2. 전제 검증: 회의록이 유효하려면 어떤 전제(참석자 식별, 모듈 맥락, 고객사 상황)가 맞아야 하는가?
3. 반대 증거: "미참석자가 읽었을 때 '이 결정 왜?' 또는 '이 약속 구체 범위?'에 답할 수 없는 부분은?" 반박 1개 이상 생성 후 갭 질문 우선순위에 반영

1차 정리 후 아래 체크리스트로 빠진 정보를 찾아 질문한다.

공통 체크리스트:

• 참석자가 불명확하거나 누락되었는가?
• 액션 아이템에 담당자가 빠져 있는가?
• 액션 아이템에 기한이 빠져 있는가?
• 결정 사항의 근거가 빠져 있는가?
• 기각된 대안이 있었는데 기록되지 않았는가?
• 발언 주체가 불명확한가?
• 맥락 없이 결론만 있는 안건이 있는가?

고객사 미팅 추가 체크리스트:

• 고객 요구사항의 우선순위가 불명확한가?
• 구두 약속 중 조건이 붙었는데 기록되지 않은 것이 있는가?
• 다음 미팅 일정이나 후속 커뮤니케이션 방법이 합의되었는가?

질문 우선순위 (상위일수록 먼저):

1. 액션 아이템 담당자/기한 (추적 불가하면 회의록 무의미)
2. 결정 근거 (나중에 "왜 이렇게 했지?" 할 때 필요)
3. 고객 구두 약속의 정확한 내용 (분쟁 방지)
4. 발언 주체
5. 배경/맥락 보충

질문 형식:

**빠진 정보. 답해주시면 회의록이 더 완성됩니다**

1. [질문 내용] (이유: [왜 필요한지])
2. ...

답해주시면 반영해서 업데이트합니다.
"이 정도면 됐어"라고 하시면 현재 버전으로 확정합니다.

파일 저장

Frontmatter (CONTRACT 7-2절 표준): category: meetings, retention: 30d, harvest_targets: [biz-rules.md, customers/*.md]

회의록이 확정되면 반드시 마크다운 파일로 저장한다.

프로젝트 연관 판단

1. $ARGUMENTS에 프로젝트명이 있으면 해당 프로젝트
2. 대화 맥락에서 프로젝트가 특정되면 해당 프로젝트 (예: "{프로젝트 키워드} 회의"면 .local.claude/projects/{프로젝트명})
3. ls .local.claude/projects/로 기존 프로젝트 확인 후 관련 있으면 해당 프로젝트
4. 어디에도 해당 안 되면 독립 저장

저장 경로

• 프로젝트 관련이면 .local.claude/projects/{project-name}/meetings/YYYY-MM-DD-{간략설명}.md
• 독립적이면 .local.claude/meetings/YYYY-MM-DD-{간략설명}.md
• 디렉터리 없으면 mkdir -p로 생성

저장 시점

• 사용자가 "완료", "끝" 등을 말해 최종본 확정 시 자동 저장
• 저장 후 파일 경로를 사용자에게 안내

다음 스킬 연결

최종본 확정 후 안내:

• 아이디어 발산이 필요하면 /brainstorm {저장된 파일 경로}
• 바로 기획 문서로 전환하려면 /prd {저장된 파일 경로}
• 버그/장애 회의였으면 /cs 또는 /issue

다른 스킬과의 경계

질문	담당	이 스킬에서
회의 메모와 전사본을 구조화된 회의록으로 정리 (갭 질문 반복)	이 스킬	핵심. 회의록 작성 SSOT
최근 커밋 기반 오늘의 변경과 영향 브리핑	/briefing	다루지 않음. 코드 변경 분석은 위임
회의록 내용을 수신자에 맞는 메시지/보고로 가공	/draft	회의록 경로 전달만. 전달 가공은 위임

제약조건

• 외부-가시 문서 공통 원칙 준수: rules/external-doc.md (가독성 5 + 정직성 5). 고객사 미팅과 외부 참석자 전제 회의록은 10원칙 공통 적용. 팀 내부 비공식 회의록은 유연 적용 가능.
• 사용자가 말한 내용만 정리. 추측으로 채우지 않음. 불명확한 것은 [미확인]으로 표시.
• 음성 전사본의 구어체는 문어체로 다듬되, 핵심 표현과 뉘앙스는 보존. 특히 고객 발언은 원래 표현을 최대한 살림.
• 전사본에서 화자가 구분되지 않으면 [화자 미확인]으로 표시하고 질문에 포함.
• 액션 아이템은 반드시 "검증 가능한 형태"로. "검토한다" (X)가 아니라 "검토하여 [산출물]을 [기한]까지 공유한다" (O)
• 결정 사항에는 근거를 반드시 포함. 근거가 입력에 없으면 [미확인]으로 표시하고 질문.
• 회의록 분량은 실제 회의 내용에 비례. 간결함 우선.
• 사용자가 "완료", "끝" 등을 말하면 추가 질문 없이 최종본 확정.
• 최종 확정 시 회의록 상단에 [최종본]을 표시하고, 남은 [미확인] 항목이 있으면 하단에 일괄 정리.

예시

예시 1: 팀 내부 회의 (간결 입력)

사용자: "오늘 스프린트 회의함. {팀원}이 {모듈} 성능 이슈 얘기. {조건} 넘으면 느려진대."

• 1단계: 팀 내부 회의 판단
• 2단계: 팀 내부 회의 구조로 1차 정리 (CLAUDE.md 에서 모듈과 기술 스택 확인)
• 3단계: 담당자/기한/결정근거 등 갭 질문

예시 2: 고객사 미팅

사용자: "{고객사} 미팅. {담당자}가 {요구사항}을 요청. 된다고 했고 공수 확인 후 회신하겠다고 약속."

• 1단계: 고객사 미팅 판단 ({고객사})
• 2단계: 고객사 미팅 구조로 1차 정리 (관련 모듈 modules/{name}.md 참조)
• 3단계: 회신 기한, 참석자, 요구사항 배경 등 갭 질문

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[사용자 개입 필요] 회의 유형 (내부 vs 고객) 판단 모호

• 신호: 입력에 고객사 이름, 외부 참석자, 내부 팀원이 섞여 있거나 단서 부재
• 대응: AskUserQuestion 으로 유형 확인 + 유형별 구조(내부 회의 / 고객 미팅)로 분기

[데이터 결함] 결정 근거 부재

• 신호: "결정" 항목은 있으나 이유, 대안 비교, 트레이드오프가 기록 안 됨
• 대응: 결정 항목에 [미확인] 태그 + "추후 ADR 로 기록 권장" 안내 + 빠진 근거를 사용자에게 확인 질문