send-email

${var} — who to email and why, e.g. [email protected] | subject=Intro | about=propose a 20-min call on X. Freeform also works ("email [email protected] to follow up on yesterday's demo"). cc= is optional. The reply-shape revise:<instruction> (Telegram force-reply, e.g. revise:make it warmer) refines the last composed draft for review only — it never sends.

Read soul/ (for voice) and memory/MEMORY.md (for context) before composing.

What this does

Composes a single, purposeful email and sends it in-run via Resend (./secretcurl), gated by the shared send caps + kill-switch and logged to the shared ledger memory/email-log.json. The send is irreversible, so it's the skill's final action, behind a set of fail-closed checks (see "Send (in-run)" below): a skipped or failed check means do not send, never send anyway. This is the general-purpose sibling of vuln-scanner's disclose arm (Arm C, var=disclose) — same caps + audit CC, any recipient and purpose instead of only vuln maintainers.

This is not a bulk or cold-outreach tool. One deliberate recipient per run, with a genuine reason to write. If the request reads as mass-mailing, list-blasting, or spam, refuse and log SEND_EMAIL_REFUSED: not a 1:1 purposeful email.

Steps

Revise intercept (Telegram force-reply — re-stage for review only, NEVER auto-send)

Before anything else, if ${var} starts with revise:, the operator replied to a "refine this email?" prompt. Handle it here and end the run — the normal compose/send flow below does NOT run, and nothing is ever sent:

1. Strip the prefix. The instruction is ${var#revise:} (keep any inner colons), e.g. make it warmer, shorten to 3 lines, drop the meeting ask.
2. Load the last draft from memory/drafts/send-email-latest.md (the review copy the normal run saves in step 4). If it's missing or empty, there's nothing to refine: send ./notify "Nothing to revise yet — compose an email first, then reply here to refine it." and end the run.
3. Regenerate the email applying the instruction — re-read soul/ for voice; keep the same recipient / cc / subject unless the instruction changes them; keep the body as the exact send-ready text (operator-only notes stay out).
4. Re-stage for REVIEW ONLY. Overwrite memory/drafts/send-email-latest.md with the revised draft. Do NOT run the Send step. A revise: reply never sends — the operator confirms a real send by invoking send-email normally (which re-composes and sends in-run).
5. Notify the operator with the full revised draft for review — multi-line ⇒ ./notify -f <file>:

   revised draft (not sent) → <to>: <subject>
   
   <body>
   

6. Re-offer a further revision (the operator is iterating — skip the daily dedup guard here):

   ./notify "Want another pass? Reply with a change and I'll revise the draft again (still won't send)." \
     --force-reply --placeholder "e.g. make it warmer" \
     --context "send-email::revise"
   

7. Log - SEND_EMAIL_REVISED (draft re-staged for review, not sent) under a ### send-email heading in memory/logs/${today}.md, then end the run.