aana-email-send-guardrail

by mindbomber

Install this Skill

curl -fsSL -o aana-email-send-guardrail.zip https://skill.seembox.com/api/v1/skills/aana-email-send-guardrail/download && unzip aana-email-send-guardrail.zip

Download aana-email-send-guardrail.zip

SKILL.md About

# 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.

_meta.json Metadata

{
  "ownerId": "kn7cgkmd5zmvhysnw2553a3gk185za2x",
  "publishedAt": 1777839693163,
  "slug": "aana-email-send-guardrail",
  "version": "1.0.0"
}