email-ops

Email Ops

실제 작업이 메일함 작업일 때 사용합니다. triage, 초안 작성, 답장, 발송, Sent 확인이 대상입니다.

이건 일반적인 글쓰기 스킬이 아닙니다. 실제 메일 표면을 둘러싼 운영자 워크플로입니다.

스킬 스택

관련 시 다음 ECC 네이티브 스킬을 조합합니다.

• brand-voice: 사용자 대면 초안 작성 전
• investor-outreach: 투자자, 파트너, 스폰서 대상 메일일 때
• customer-billing-ops: 일반 서신이 아니라 결제/지원 이슈 스레드일 때
• knowledge-ops: 메시지나 스레드를 장기 컨텍스트에 저장해야 할 때
• research-ops: 답장이 최신 외부 사실에 의존할 때

사용 시점

• 사용자가 inbox triage나 저신호 메일 보관을 요청할 때
• 초안, 답장, 신규 아웃바운드 이메일을 원할 때
• 메일이 이미 전송됐는지 확인하고 싶을 때
• 어떤 계정, 스레드, Sent 항목을 사용했는지 증명이 필요할 때

가드레일

• 사용자가 명확히 실발송을 요청하지 않는 한 먼저 초안을 작성합니다
• 실제 Sent 폴더 또는 클라이언트 측 확인 없이는 전송됐다고 주장하지 않습니다
• 발신 계정을 함부로 바꾸지 않습니다. 프로젝트와 수신자에 맞는 계정을 고릅니다
• 정리 중에도 확실하지 않은 업무 메일은 삭제하지 않습니다
• 실제 작업이 DM이나 iMessage라면 messages-ops로 넘깁니다

워크플로

1. 정확한 표면 확정

실행 전 다음을 확정합니다.

• 어떤 메일 계정인지
• 어떤 스레드 또는 수신자인지
• 작업이 triage, draft, reply, send 중 무엇인지
• 사용자가 draft-only를 원하는지 live send를 원하는지

2. 작성 전에 스레드 읽기

답장이라면:

• 기존 스레드를 읽고
• 마지막 아웃바운드 접점을 확인하고
• 약속, 마감, 미답 질문을 식별합니다

새 아웃바운드라면:

• 관계의 온도를 파악하고
• 맞는 채널과 발신 계정을 고르고
• 초안 전에 brand-voice를 가져옵니다

3. 초안 후 검증

draft-only 작업이라면:

• 최종 문안을 만들고
• 발신자, 수신자, 제목, 목적을 명시합니다

live-send 작업이라면:

• 정확한 최종 본문을 먼저 확인하고
• 선택한 메일 표면으로 발송한 뒤
• Sent 또는 동등한 보낸 편지함 저장소에 남았는지 확인합니다

4. 정확한 상태 보고

상태어는 정확히 사용합니다.

• drafted
• approval-pending
• sent
• blocked
• awaiting verification

발송 표면이 막히면 초안을 보존하고, 말 없이 다른 전송 수단으로 우회하지 말고 정확한 blocker를 보고합니다.

출력 형식

MAIL SURFACE
- account
- thread / recipient
- requested action

DRAFT
- subject
- body

STATUS
- drafted / sent / blocked
- proof of Sent when applicable

NEXT STEP
- send
- follow up
- archive / move

함정

• Sent 확인 없이 발송 성공을 주장하지 않습니다
• 스레드 히스토리를 무시한 맥락 없는 답장을 쓰지 않습니다
• 메일함 작업과 DM/문자 워크플로를 섞지 않습니다
• 시크릿, 인증 정보, 불필요한 메시지 메타데이터를 노출하지 않습니다

검증

• 답변에 계정과 스레드 또는 수신자가 명시된다
• 전송을 주장하면 Sent 증거 또는 명시적 클라이언트 확인이 포함된다
• 최종 상태가 drafted / sent / blocked / awaiting verification 중 하나다