contact-context

구직 폴더({user_dir}) 확인: 먼저 현재 작업 디렉터리에서 CareerLoop/ 폴더(또는 한 단계 위·아래)를 찾아 그 폴더가 들어 있는 디렉터리를 {user_dir}로 쓴다. 홈 디렉터리 전체를 검색하지 않는다. 작업 디렉터리에서 찾지 못하면 사용자에게 경로를 묻고, 그래도 없으면 /careerloop:launch를 안내한다.

Gmail / Microsoft 365(호스트가 제공하는 경우 캘린더 포함)에서 근거가 있는 컨텍스트를 수집하여 **draft-outreach**와 **writer**가 이전 대화를 추측하지 않도록 합니다.

미팅 이력 파악(웜 네트워킹 식별): 캘린더 도구를 사용할 때는 이 연락처가 포함된 과거 및 예정된(upcoming) 이벤트를 조회합니다. 캘린더에 예정된 미팅이 있다면 관계가 콜드가 아니라 웜이라는 강한 신호이므로, 아웃리치에서 예정된 시간을 언급하거나 불필요한 “첫 접촉” 프레이밍을 피할 수 있습니다. 예정된 미팅이 없더라도 과거 미팅이 있으면 웜 후속 조치의 근거가 됩니다. 참석자 매칭이 불확실하면 **caveats**에 불확실성을 표시합니다.

게이트 (가장 먼저 실행)

1. 커넥터: 이 세션에 Gmail/M365(받은편지함) 도구도 없고 호스트 캘린더 도구(예: Google Calendar, Microsoft 365를 통한 Outlook/Teams 캘린더)도 없으면 중단하고 CONNECTORS.md와 /careerloop:launch 6단계를 안내합니다. 받은편지함이나 캘린더 접근을 지어내지 않습니다.
2. 명시적 승인: 도구를 호출하기 전에 한 번 묻습니다. 사용 가능한 범위를 포함합니다. 예:

   “**{이름 또는 회사}**가 포함된 스레드를 메일에서 검색하고 [그분과의 과거 및 예정된 미팅을 캘린더에서 확인]하겠습니다. 읽기 전용입니다. 이번 요청에 대해 승인하시겠습니까?”
   (대괄호 안의 캘린더 문장은 캘린더 도구가 있고 사용자가 미팅 컨텍스트를 원할 때만 포함합니다.)
   호스트가 메일만 또는 캘린더만 제공하면 해당 범위만 묻습니다. 사용자가 거절하면 짧은 안내와 함께 종료하며, 지어낸 요약은 절대 만들지 않습니다.

입력 (없으면 질문)

• 연락처: 이름, 이메일 또는 LinkedIn 식의 식별자. 회사(선택이지만 구분에 도움이 됩니다).
• 범위: 기본값 = 최근 약 12개월의 관련 스레드이며, 사용자가 좁히거나 넓힐 수 있습니다. 캘린더의 기본값 = 과거 약 12개월 + 향후 약 6개월(또는 도구 기본값)으로, 이 연락처와 예정된 미팅이 포함되게 합니다.

사용자가 보냈다고 함 — 사용자를 믿는다 (기본값)

사용자가 이메일을 보냈다고 하면(또는 반송됨 / 실패 / 주소 오류), 그 말을 믿습니다. Gmail MCP로 발송을 증명하거나 반송/NDR을 찾느라 세션을 쓰지 않습니다. 이 용도에는 적합하지 않습니다(연산자가 적용되지 않는 경우가 많고, 결과가 임의의 받은편지함/보낸편지함처럼 보일 수 있습니다).

대신 즉시 방향을 바꿔 이 연락처의 올바른 이메일 주소(또는 근거가 있는 후보 단기 목록)를 찾도록 돕습니다.

1. tracker.json / profile.md — 이 사람에 대해 저장된 이메일, 직함, 회사가 있는지 확인합니다. 주소는 tracker.json이 아니라 회사 연락처 파일에 있습니다. 그 회사의 요약 행을 찾아 {user_dir}/CareerLoop/ + 해당 contacts_file을 로드하고, contacts[] 중 application이 그 행의 application 레이블과 같은 항목만 필터링합니다. 등록된 것이 없다고 결론 내리기 전에 그 회사의 모든 지원 건을 확인하고 name으로 중복을 제거합니다.
2. MCP에서 실제로 동작하는 메일 검색: 일반 텍스트 Firstname Lastname, company, 간단한 주소나 도메인을 쓴 to: / from:(한 번에 한 절씩). 사용자가 반송 메시지를 찾아달라고 명시적으로 요청하지 않는 한 **mailer-daemon**이 아니라 보낸편지함과 받은편지함의 실제 스레드(서명, 전달, 캘린더 초대)를 봅니다.
3. 합리적인 변형 — 대체 도메인(모회사 vs 자회사), first.last, firstlast, flast — 각각 **추측(guess)**인지 출처에서 **인용(cited)**한 것인지 표시합니다.
4. 커넥터가 확인해 주지 못하면 사용자에게 LinkedIn, 회사 사이트 또는 이전 답장에서 주소를 붙여넣어 달라고 요청합니다.
5. 후보와 신뢰도를 **email_address_notes**에 넣고, **search_method_notes**에 반송 검색을 건너뛰었다는 점(MCP 한계)과 사용자의 발송 시도를 말 그대로 받아들였다는 점을 설명합니다.

선택적 반송 조회: 사용자가 반송 메시지를 찾아달라고 명시적으로 요청하고 그 일에 시간을 쓰는 것을 승인한 경우에만 from:mailer-daemon(단일 토큰)을 시도하고 이 주소/이름에 대한 최근 시스템 메시지 몇 건을 읽습니다. 단, “결과 없음”을 어떤 것의 증거로도 취급하지 않습니다. 필요하면 사용자가 Gmail 웹에서 반송 메시지를 붙여넣는 편이 낫습니다.

이름 검색 (스레드를 찾지 못했을 때)

(아래) 2단계에서 명확한 스레드가 나오지 않으면 연락처의 전체 이름을 일반 텍스트(예: Jordan Kim)로 메일에서 검색한 다음 이름 + 회사로 검색합니다. 도구가 허용하면 전체 보관함(All Mail) / 넓은 범위를 선호합니다.

워크플로

지원 데이터는 references/tracker-schema.md에 정의된 분할 레이아웃을 사용합니다. 읽기나 쓰기 전에 반드시 해당 문서를 읽습니다.

1. {user_dir}/CareerLoop/profile.md, tracker.json(요약 행), 해당 회사 연락처 파일, networking.json(networking[], recruiter_relationships[])을 읽어 이 사람에 대해 이미 알려진 사실을 확인합니다. 트래커의 근거와 모순되지 않도록 합니다.

   연락처 조회(applications[].contacts[]가 아니라 아래 방법을 사용합니다. 그 배열은 더 이상 존재하지 않습니다):

   1. tracker.json에서 연락처의 회사에 해당하는 요약 행을 찾습니다.
   2. 행에서 contacts_file을 가져와 {user_dir}/CareerLoop/ + 해당 경로(contacts/<company-slug>.json)를 로드합니다. slug를 직접 만들어 내지 않으며, contacts_file이 없는 행은 등록된 연락처가 없는 것입니다.
   3. 파일의 contacts[] 중 **application**이 그 행의 application 레이블("<company> — <role>")과 같은 항목만 필터링합니다. 회사 파일 하나가 그 회사의 모든 지원 건을 담당하므로, 필터링하지 않은 항목은 다른 직무에 속한 것입니다.
   4. 연락처가 그 회사의 여러 지원 건에 걸쳐 있을 수 있으면 관련된 각 행에서 일치 항목을 모으고, 제시하거나 요약하기 전에 name 기준으로 중복을 제거합니다. 같은 사람이 지원 건마다 하나씩 항목을 가집니다.
   5. 일치한 항목에서 title, relationship, notes, 이전 interactions[](날짜, 유형)를 가져와 알려진 사실의 기준선으로 삼습니다.

   단계나 노트 컨텍스트(예: "온사이트에서 만났다")는 행의 detail_file(applications/<application_id>.json)을 읽되, 실제로 진행 중인 지원 건에 한해서만 읽습니다. 행의 latest_stage, latest_stage_date, notes_count, stage_count만으로 대개 답이 나오므로 아무것도 열지 않아도 되는 경우가 많습니다.

   이 세션에 받은편지함 도구가 없으면 아래 메일 검색을 건너뛰고 caveats에 기록합니다. 캘린더 도구가 없으면 캘린더 단계를 건너뛰고 calendar_notes, upcoming_meetings, warm_networking을 상황에 맞게 "—" 또는 **not searched — no calendar tools**로 설정합니다.

2. 승인을 받은 후 호스트의 Gmail / Microsoft 365 도구로 관련 스레드를 검색하고 읽습니다(주소, 도메인, 회사, 일반 이름 기준). 읽기 전용: 메일을 보내거나 초안을 작성하거나 삭제하지 않습니다. 1단계에서 받은편지함 도구가 없다고 확인되었다면 건너뜁니다.
3. 캘린더(도구가 있고 승인에 캘린더가 포함된 경우): Google Calendar 및/또는 Microsoft 365 캘린더 도구로 연락처가 참석자(이메일 일치)로 나오거나 제목/설명/장소가 해당 인물이나 회사를 그럴듯하게 언급하는 이벤트를 찾습니다. 다음을 다룹니다.
   • 과거: 조회 기간(기본 약 12개월) 안에 이미 발생한 이벤트 — 노트/설명에 있는 약속이나 다음 단계.
   • 예정/향후: 오늘부터 향후 기간(기본 약 6개월 또는 호스트 한도)까지의 이벤트 — 날짜, 시간(가능한 경우), 제목. 이는 웜 네트워킹 식별을 뒷받침합니다. 이 연락처와 미팅이 예정되어 있으면 해당 스레드를 웜으로 취급하고 그 신호를 **hooks_for_writer**에 전달합니다(예: “목요일 예정된 1:1 — 확인하거나 준비 내용을 공유하는 짧은 핑”이며 콜드 인트로가 아닙니다). 읽기 전용: 사용자가 이 스킬의 범위 밖에서 명시적으로 요청하지 않는 한 이벤트를 생성, 이동, 삭제하지 않습니다.
4. 사용자가 메일을 보냈다고 하는 경우(전송 실패, 주소 오류, 또는 “이미 이메일 보냈어요”): 위의 **“사용자가 보냈다고 함 — 사용자를 믿는다 (기본값)”**를 따릅니다. 주소 확인이 우선이며, MCP를 통한 반송/NDR 탐색은 필수가 아닙니다.
5. 이름 대체 검색: 메일 검색에서 명확한 스레드가 나오지 않았고 사용자가 이를 “보냈는데 주소가 잘못됨”으로 설명하지 않았다면, 위의 **“이름 검색 (스레드를 찾지 못했을 때)”**를 실행합니다.
6. 중립적으로 요약합니다. 마지막으로 쓴 사람, 날짜, 약속, 미해결 사항(open loops), 톤. 추가로 캘린더 결과(과거 통화/면접, 예정된 미팅 — 웜 식별을 위해 이를 강조)도 포함합니다. 인용은 최소한으로 하고 불릿을 선호합니다.
7. writer / **draft-outreach**를 위해 ContactContextBrief(아래 마크다운 블록)를 출력합니다.
8. 제안: “이 컨텍스트를 반영해 다음으로 **draft-outreach**를 진행할까요?” 예라면 브리프를 다음 단계로 전달합니다(사용자가 **/careerloop:draft-outreach**를 실행하거나 채팅에서 계속할 수 있습니다).

ContactContextBrief (출력 블록)

## ContactContextBrief
- **contact:** {이름 또는 가장 적절한 라벨}
- **company:** {회사 또는 "—"}
- **sources_used:** gmail | microsoft_365 | calendar | none (실제로 조회한 것을 모두 나열)
- **as_of:** {YYYY-MM-DD}
- **summary:** {2–6개 불릿: 이전 교류의 핵심 내용과, 사용한 경우 캘린더 컨텍스트}
- **calendar_notes:** {이 연락처와의 **과거** 미팅 — 날짜, 제목, 설명에 있는 약속 — 없으면 "—"}
- **upcoming_meetings:** {이 연락처와 **예정된** 향후 이벤트 — 날짜, 알면 시간, 제목 — 없거나 검색하지 않았으면 "—"}
- **warm_networking:** {한 줄: 예: `warm — upcoming meeting scheduled` | `warm — past 1:1 only` | `uncertain — calendar partial` | `cold — no calendar match`}
- **open_loops:** {메일이나 캘린더에서 언급된 약속, 답이 없는 스레드, 마감 — 관련이 있으면 **예정된** 미팅의 준비/후속 조치 포함}
- **hooks_for_writer:** {3개 불릿 — 사실에 근거하며 아웃리치에서 언급해도 안전한 내용}
- **email_address_notes:** {이 연락처의 후보 주소 — 근거 있음 vs 잠정 — 없으면 "—"}
- **search_method_notes:** {예: 사용자가 메일을 보냈다고 확인함; 반송 탐색 생략; MCP 한계 — 없으면 "—"}
- **caveats:** {예: 부분 검색, 커넥터 한계}

제약

• 정직: 스레드나 주소를 지어내지 않습니다. 추측은 명확히 표시합니다.
• 사용자 발송: 사용자가 이메일을 보냈다고 하면 MCP로 반송 증거를 얻지 못했다는 이유로 그 말을 반박하지 않습니다.
• 개인정보: 필요한 경우가 아니면 본문 전체를 붙여넣지 않으며, 민감한 내용을 존중합니다.
• 캘린더 보강은 도구가 있고 그리고 사용자가 캘린더 범위를 승인한 경우에만 수행합니다(호스트가 별도의 캘린더 동의 단계를 요구하지 않는 한 통합 승인도 무방합니다).

스케줄링

중요한 아웃리치 주간 전에 선택적으로 **/schedule**을 사용할 수 있으며, 보통은 draft-outreach 전에 온디맨드로 실행합니다.