AANA Email Send Guardrail Skill

Ensures email recipients, content, tone, attachments, claims, and approvals are verified and safe before sending or scheduling messages.

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:

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.