
Email Ops
Triage your real inbox, draft or send mail with proof from Sent, and stack ECC skills for voice, investors, billing, research, and knowledge capture.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill email-opsWhat is this skill?
- Evidence-first workflow: never claim sent without real Sent-folder or client confirmation
- Draft-first unless the user explicitly requests a live send
- Account-matched sender selection per project and recipient—no casual account switching
- Stacks five ECC-native skills: brand-voice, investor-outreach, customer-billing-ops, knowledge-ops, research-ops
- Operator focus on the real mail surface—triage, archive, reply, and sent-mail-safe follow-up
Adoption & trust: 3k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
Recommended Skills
Journey fit
Mailbox triage, customer threads, and send verification map most naturally to running user communication after launch—where solo builders still own support and follow-up themselves. Support subphase covers billing incidents, reply workflows, and proving what was sent—core operator outcomes this skill defines beyond one-off copywriting.
Common Questions / FAQ
Is Email Ops safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Email Ops
# 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