mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-08 02:03:34 +08:00
122 lines
3.4 KiB
Markdown
122 lines
3.4 KiB
Markdown
---
|
|
name: email-ops
|
|
description: Evidence-first mailbox triage, drafting, send verification, and sent-mail-safe follow-up workflow for ECC. Use when the user wants to organize email, draft or send through the real mail surface, or prove what landed in Sent.
|
|
origin: ECC
|
|
---
|
|
|
|
# Email Ops
|
|
|
|
Use this when the real task is mailbox work: triage, drafting, replying, sending, or proving a message landed in Sent.
|
|
|
|
This is not a generic writing skill. It is an operator workflow around the actual mail surface.
|
|
|
|
## Skill Stack
|
|
|
|
Pull these ECC-native skills into the workflow when relevant:
|
|
|
|
- `brand-voice` before drafting anything user-facing
|
|
- `investor-outreach` for investor, partner, or sponsor-facing mail
|
|
- `customer-billing-ops` when the thread is a billing/support incident rather than generic correspondence
|
|
- `knowledge-ops` when the message or thread should be captured into durable context afterward
|
|
- `research-ops` when a reply depends on fresh external facts
|
|
|
|
## When to Use
|
|
|
|
- user asks to triage inbox or archive low-signal mail
|
|
- user wants a draft, reply, or new outbound email
|
|
- user wants to know whether a mail was already sent
|
|
- the user wants proof of which account, thread, or Sent entry was used
|
|
|
|
## Guardrails
|
|
|
|
- draft first unless the user clearly asked for a live send
|
|
- never claim a message was sent without a real Sent-folder or client-side confirmation
|
|
- do not switch sender accounts casually; choose the account that matches the project and recipient
|
|
- do not delete uncertain business mail during cleanup
|
|
- if the task is really DM or iMessage work, hand off to `messages-ops`
|
|
|
|
## Workflow
|
|
|
|
### 1. Resolve the exact surface
|
|
|
|
Before acting, settle:
|
|
|
|
- which mailbox account
|
|
- which thread or recipient
|
|
- whether the task is triage, draft, reply, or send
|
|
- whether the user wants draft-only or live send
|
|
|
|
### 2. Read the thread before composing
|
|
|
|
If replying:
|
|
|
|
- read the existing thread
|
|
- identify the last outbound touch
|
|
- identify any commitments, deadlines, or unanswered questions
|
|
|
|
If creating a new outbound:
|
|
|
|
- identify warmth level
|
|
- select the correct channel and sender account
|
|
- pull `brand-voice` before drafting
|
|
|
|
### 3. Draft, then verify
|
|
|
|
For draft-only work:
|
|
|
|
- produce the final copy
|
|
- state sender, recipient, subject, and purpose
|
|
|
|
For live-send work:
|
|
|
|
- verify the exact final body first
|
|
- send through the chosen mail surface
|
|
- confirm the message landed in Sent or the equivalent sent-copy store
|
|
|
|
### 4. Report exact state
|
|
|
|
Use exact status words:
|
|
|
|
- drafted
|
|
- approval-pending
|
|
- sent
|
|
- blocked
|
|
- awaiting verification
|
|
|
|
If the send surface is blocked, preserve the draft and report the exact blocker instead of improvising a second transport without saying so.
|
|
|
|
## Output Format
|
|
|
|
```text
|
|
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
|
|
```
|
|
|
|
## Pitfalls
|
|
|
|
- do not claim send success without a sent-copy check
|
|
- do not ignore the thread history and write a contextless reply
|
|
- do not mix mailbox work with DM or text-message workflows
|
|
- do not expose secrets, auth details, or unnecessary message metadata
|
|
|
|
## Verification
|
|
|
|
- the response names the account and thread or recipient
|
|
- any send claim includes Sent proof or an explicit client-side confirmation
|
|
- the final state is one of drafted / sent / blocked / awaiting verification
|