email-analysis

name	email-analysis
version	1.3.0
category	productivity
description	수신 메일을 업무 관점에서 깊이 읽는다 — 맥락을 추론으로 엮어 '왜 지금', 이해관계자, 리스크·기한, 다음 단계를 드러낸다. Use when: 새 메일 분석, 메일 검토 요청, '이 메일 분석해줘', 메일이 도착했을 때. NOT for: 단순 메일 발송·회신, 일반 대화, 모닝레터 작성(morning-letter 사용).
metadata	{"deneb":{"emoji":"📬","tags":["email","analysis","메일","분석","triage","업무"],"related_skills":["morning-letter"]}}
user-invocable	true

메일 분석

수신 메일 한 건을 업무 관점에서 깊이 읽는다. 이건 절차서가 아니라 분석 자세다. 정해진 칸을 채우지 말고, 그 메일이 무엇을 말하는지 추론으로 풀어내라.

When to Use

• 새 메일이 도착해 분석이 필요할 때
• 사용자가 특정 메일을 붙여넣고 "분석해줘"라고 할 때
• 진행 중인 프로젝트·거래 관련 메일을 검토할 때

쓰지 않는 경우: 단순 회신/발송, 일반 대화, 일일 브리핑(→ morning-letter).

분석 자세

메일은 고립된 사건이 아니다. 이 메일이 왜 지금 왔는지를 먼저 생각하라 — 직전에 무슨 합의가 있었고, 무엇이 바뀌었고, 누가 무엇을 움직였나. 관련 과거를 시간선으로 복원하면 메일의 진짜 의미가 드러난다.

그다음 사람을 본다. 누가 누구에게, 어떤 입장에서 보냈나. 실무 라인과 결정 라인이 어떻게 갈리나. 담당자 교체나 에스컬레이션처럼 평소와 다른 신호가 있나. 그리고 시간과 돈에 민감한 것 — 결제 기한, 마감일, 금액, 미해결 이슈 — 은 절대 묻히지 않게 한다. 그 원문 수치·조건은 본문이 아니라 첨부(견적서·계약서· 세금계산서)에 담겨 오는 일이 많으니, 첨부가 있으면 반드시 열어서 확인한다. 마지막은 추측이 아닌 구체적인 다음 행동이다.

무엇을 앞세우고 어떻게 묶을지는 그 메일이 정한다. 어떤 메일은 타임라인이 전부고, 어떤 메일은 한 사람의 결정이 핵심이다. 고정된 섹션 틀에 끼워 맞추지 말고, 사안에서 중요한 것이 먼저 오게 하라. 짧으면 짧게, 복잡하면 깊게 — 분량도 사안이 정한다.

근거가 있는 것만 말하라. 날짜나 사실을 추측으로 메우지 말고, 모르는 것은 모른다고 둔다.

쓸 수 있는 것

추론을 뒷받침하는 자원이다. 의무 단계가 아니라, 맥락을 채우는 데 필요할 때 쓴다.

• 스레드·메일 이력 — 수신 메일을 읽고 분석하는 정식 경로는 로컬 아카이브 mail_archive 도구다. thread 액션(결과의 Locator/ID 전달, 없으면 제목·참여자 fallback)으로 같은 대화를 시간순 복원하고, project_history 액션으로 그 거래처· 프로젝트의 메일 타임라인과 스레드 후보를 한 번에 불러온다. "왜 지금"의 근거는 보통 여기 있다. 에이전트 표면의 직접 Gmail 도구는 제거되었으므로 수신 메일 조회· 스레드 복원·이력은 모두 mail_archive로 처리한다.
• 첨부 문서 — 견적서·계약서·세금계산서·거래명세서·발주서의 핵심 숫자·조건은 본문이 아니라 첨부 파일 안에 있다. mail_archive의 attachment 액션으로 그 메일의 첨부를 직접 열어 읽는다(message_id 또는 query로 메일을 지정하고, attachment로 파일 선택 — 파일명 일부나 1-기반 인덱스, 비우면 전체). 본문이 "견적서 첨부", "카탈로그 첨부"라고만 하고 넘어가면 그 말을 받아쓰지 말고 실제 첨부를 열어 단가·수량·금액·납기·조건을 확인하라. (자동 분석 경로는 첨부를 일부 미리 주입하지만, 비어 있거나 "일부만 반영"으로 표시됐으면 이 액션으로 전체를 읽는다. 수신 메일 첨부도 mail_archive가 정식 경로다.)
• 위키 이력 — 메일에 나온 프로젝트·회사·인물을 wiki에서 찾는다. 과거 진행 상황이 있어야 무엇이 달라졌는지 보인다.
• 거래 기록 — 금액·납기가 걸린 건은 분석 뒤 wiki의 거래 카테고리에 남긴다. 가장 임박한 결제기한·마감일은 due 필드(YYYY-MM-DD)에 넣으면 모닝레터의 "임박 마감"이 자동으로 챙긴다. 페이지 골격은 templates/deal-page.md. 단가·수량·금액이 이전과 달라졌으면 변경 전후를 모두 남긴다.
• 소관 부서 태그 — 프로젝트·거래 페이지를 만들거나 고칠 때, 담당자(탑솔라/ 남도에코)를 보고 소관을 판별해 tags에 소관:<팀>을 단다 — 소관:1팀(사업개발)· 소관:2팀(루프탑·RE100·주차장)·소관:3팀(모듈)·소관:남도에코(전선·케이블)· 소관:개인(실장 직속). 담당자→팀 매핑은 knowledge/org-기획조정실-2026-06.md 참조. ⚠️ 위키는 frontmatter 커스텀 필드를 보존하지 않으니 반드시 tag로 단다. 이 태그가 주간업무보고의 팀 분류 근거다.

분석으로 새로 안 사실은 위키에 갱신해 다음 분석의 연속성을 확보한다.

주의

지금 응답하는 곳이 곧 사용자의 채널이다 — "텔레그램 연결 안 됨", "여기에 직접 전달" 같은 채널 상태 추측을 쓰지 마라. 내부 토큰(<thinking>, NO_REPLY)이 새지 않게 하고, 긴 분석도 핵심 위주로 분량을 조절한다. "좋은 질문입니다" 같은 빈 서두 없이 분석부터 시작한다.