Ensures email recipients, content, tone, attachments, claims, and approvals are verified and safe before sending or scheduling messages.
# AANA Email Send Guardrail Skill Use this skill when an OpenClaw-style agent may draft, revise, forward, reply to, schedule, or send an email or email-like message. This is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or run a checker on its own. ## Core Principle Before email is sent, the agent should verify the recipient, purpose, tone, private data, attachments, claims, and explicit permission for the irreversible send action. The agent should separate: - drafting an email, - revising an email, - asking for missing details, - preparing an email for user review, - scheduling or sending an email with explicit approval, - blocking unsafe or unauthorized email. ## When To Use Use this skill before: - sending, scheduling, forwarding, replying to, or CC/BCCing email, - attaching files, images, PDFs, logs, reports, account records, screenshots, or exports, - including customer, employee, student, patient, legal, financial, account, billing, payment, or personal data, - promising refunds, credits, deadlines, prices, policy exceptions, legal outcomes, medical guidance, job decisions, or commitments, - emailing external recipients, groups, mailing lists, executives, customers, partners, vendors, regulators, or public addresses. ## Email Status Classify the email action: - `draft_only`: prepare content but do not send. - `needs_recipient`: recipient, CC, BCC, or audience is unclear. - `needs_tone_revision`: tone, wording, or emotional framing needs work. - `needs_redaction`: private or sensitive content must be removed. - `needs_attachment_review`: attachments need verification, redaction, or permission. - `needs_claim_evidence`: claims, promises, or policy statements need evidence. - `needs_approval`: the send action or scope needs explicit approval. - `ready_to_send`: recipient, content, attachments, claims, and approval are ready. - `block_send`: unsafe, unauthorized, deceptive, privacy-violating, or materially unsupported. ## AANA Email Gate Loop 1. Identify the email action: draft, revise, reply, forward, schedule, or send. 2. Identify recipients: To, CC, BCC, groups, aliases, domains, and external/internal status. 3. Check authorization: did the user explicitly approve sending to these recipients? 4. Check purpose and scope: is the message limited to the user's requested outcome? 5. Check tone: professional, clear, appropriate, not manipulative, threatening, misleading, or overconfident. 6. Check private data: secrets, account data, billing/payment data, health/legal/financial data, personal data, and unrelated details. 7. Check attachments: correct files, safe filenames, redaction, permissions, and target recipients. 8. Check claims: facts, promises, commitments, citations, policies, deadlines, prices, and uncertainty. 9. Choose action: draft, revise, ask, redact, review attachments, retrieve evidence, request approval, send, or block. ## Required Pre-Send Checks Before sending, verify: - email action, - exact recipients, - subject and purpose, - approval status, - tone status, - private data status, - attachment status, - claim evidence status, - external impact, - recommended action. ## Recipient Rules Do not send when: - the recipient is missing, ambiguous, mistyped, or inferred, - CC/BCC would expose recipients or private context unexpectedly, - a group/list alias could send to a broader audience than intended, - internal information is going to an external recipient without clear approval, - the email replies to or forwards a thread with unrelated private history. Ask for confirmation when the recipient list or audience is not exact. ## Privacy Rules Do not send: - secrets, credentials, keys, tokens, cookies, auth headers, or security codes, - full payment numbers, bank details, tax IDs, government IDs, or account recovery data, - raw medical, legal, financial, HR, student, customer, or support records, - unrelated private messages, full logs, full transcripts, hidden thread history, or internal notes, - private details about another person unless necessary and authorized. Prefer redacted summaries, minimal necessary facts, and removing old thread content when forwarding. ## Attachment Rules Before attaching or forwarding files, verify: - filename, - file type, - intended recipient, - whether the file is the current version, - whether it contains private data, - whether it is needed, - whether sharing is authorized. Do not send attachments when the file is ambiguous, stale, private beyond scope, or not explicitly approved. ## Claim And Promise Rules Do not send unsupported claims or promises about: - refunds, credits, discounts, purchases, renewals, cancellations, bookings, or billing, - legal, medical, tax, financial, employment, housing, education, insurance, or compliance outcomes, - deadlines, availability, roadmap, product behavior, security, privacy, reliability, or policies, - test results, research results, benchmarks, citations, or customer facts. If evidence is missing, revise the email, retrieve evidence, or route to review before sending. ## Tone Rules Revise before sending when tone is: - hostile, sarcastic, shaming, threatening, or manipulative, - too casual for a high-impact message, - overconfident about uncertain facts, - evasive about limitations, - likely to escalate conflict unnecessarily. Prefer concise, respectful, specific, and accountable wording. ## Send Approval Rules Drafting is not sending approval. Require explicit user approval before: - sending or scheduling an email, - forwarding a thread, - adding recipients, - attaching files, - making commitments, - sending sensitive, external, financial, legal, medical, HR, customer, or account-related email. Approval should name the recipients, subject, attachments, and send timing. ## Review Payload When using a configured AANA checker, send only a minimal redacted review payload: - `email_action` - `recipient_summary` - `subject_summary` - `approval_status` - `tone_status` - `privacy_status` - `attachment_status` - `claim_evidence_status` - `send_risk_level` - `recommended_action` Do not include raw secrets, credentials, full private records, full logs, full transcripts, full email threads, full account records, or unrelated private data when a redacted summary is enough. ## Decision Rule - If the email is only a draft, produce the draft and do not send. - If recipients, purpose, or approval are unclear, ask. - If tone needs work, revise. - If private data appears, redact. - If attachments are present, verify and request approval. - If claims or promises are unsupported, retrieve evidence, revise, or route to review. - If all checks pass and the user explicitly approved sending, send or schedule. - If sending would be unsafe, unauthorized, deceptive, privacy-violating, or harmful, block send. - If a checker is unavailable or untrusted, use manual email review. ## Output Pattern For email-sensitive work, prefer: ```text AANA email gate: - Action: draft_only / revise / reply / forward / schedule / send - Recipients: exact / missing / ambiguous / external / group_alias - Approval: approved / required / unclear / denied - Tone: ready / revise / high_impact / conflict_risk - Privacy: clear / needs_redaction / sensitive / unknown - Attachments: none / verified / needs_review / ambiguous / blocked - Claims: supported / partial / missing / risky / not_applicable - Decision: draft / revise / ask / redact / review_attachments / retrieve / request_approval / send / block ``` Do not include this gate in the user-facing answer unless review, approval, revision, or a send blocker needs to be explained.
don't have the plugin yet? install it then click "run inline in claude" again.