AANA Support Reply Guardrail Skill

SKILL.md

# AANA Support Reply Guardrail Skill

Use this skill when an OpenClaw-style agent may draft, revise, send, summarize, or approve a customer support reply.

This is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or execute a checker on its own.

## Core Principle

Customer support replies should be helpful without inventing account facts, promising outcomes the agent cannot verify, overstating policy, or exposing private data.

The agent should separate:

- facts provided by the customer,
- facts available from authorized support tools,
- policy text actually available to the agent,
- missing facts that require lookup or escalation,
- private data that should be minimized or redacted,
- actions the agent can safely take,
- actions that require human or system approval.

## When To Use

Use this skill before:

- sending or drafting support emails, chats, tickets, or helpdesk replies,
- answering refund, cancellation, charge, subscription, delivery, warranty, eligibility, or account questions,
- summarizing customer records or ticket history,
- making policy, billing, payment, legal, health, account, shipping, or entitlement claims,
- using customer data to personalize a reply,
- apologizing for facts that are not verified,
- promising refunds, credits, replacements, exceptions, escalations, timelines, or outcomes.

## Support Risk Classes

Treat these as higher risk:

- refund, credit, chargeback, cancellation, subscription, or billing promises,
- policy interpretation, exception handling, eligibility, warranty, or legal claims,
- account status, delivery status, order status, identity, address, payment, or private ticket history,
- health, legal, financial, employment, student, family, or personal support contexts,
- replies that reference internal notes, private records, another person's data, or sensitive attachments,
- responses that may bind the organization to an action, timeline, promise, or admission.

## AANA Support Reply Loop

1. Identify the customer request and the reply the agent is about to send.
2. Classify claims: customer-provided, tool-verified, policy-backed, inferred, unsupported, private, or promissory.
3. Check account facts: do not invent order status, subscription state, billing outcome, refund eligibility, identity, or timeline.
4. Check policy claims: cite or paraphrase only policies actually available; avoid overstating exceptions or guarantees.
5. Check promises: do not promise refunds, credits, replacements, cancellations, escalations, callbacks, or legal outcomes unless authorized.
6. Check privacy: remove unnecessary private details and avoid exposing another person's data.
7. Choose action: accept, revise, ask, retrieve, defer, refuse, or route to human review.

## Required Pre-Flight Checks

Before sending a support reply, verify:

- the customer-visible task,
- the exact account or order facts being asserted,
- whether each important claim is supported by tool evidence, customer-provided text, or policy,
- whether the reply includes a promise, guarantee, admission, exception, or outcome,
- whether the user is authorized to receive the private details included,
- whether sensitive details can be minimized,
- whether the answer should ask for more information or defer to a support system.

## Invented Fact Rules

Revise or defer if the reply claims unsupported facts such as:

- "Your refund has been approved."
- "Your account was cancelled."
- "Your package will arrive tomorrow."
- "The charge was a mistake."
- "You are eligible for a replacement."
- "Your subscription is active."
- "We called you earlier."
- "Your case is resolved."

Safer alternatives:

- "I do not have enough verified information to confirm that yet."
- "Please check the account record before confirming eligibility."
- "Based on the details provided, the next step is..."
- "I can help route this for review."

## Refund And Policy Promise Rules

Do not promise:

- refunds,
- credits,
- replacements,
- charge reversals,
- cancellation completion,
- policy exceptions,
- legal or compliance outcomes,
- delivery dates,
- callback or escalation timelines,
- compensation.

Unless the agent has explicit authorization from a reviewed system or human, use conditional language:

```text
The support team can review whether this qualifies.
I can help submit the request for review.
Eligibility depends on the account record and policy review.
```

## Private Data Rules

Minimize or remove:

- account IDs, order IDs, addresses, phone numbers, emails, payment details,
- billing history, invoices, balances, subscriptions, and payment methods,
- private ticket notes, internal comments, attachments, screenshots, logs,
- another person's account or support history,
- health, legal, financial, employment, school, family, or personal details.

Do not include raw secrets, credentials, full payment numbers, private messages, or unrelated account details.

## Tone And User Experience

Use clear, calm, customer-facing language:

- acknowledge the issue without admitting unverified fault,
- state what is known and what is not known,
- offer the next safe step,
- avoid blaming the customer,
- avoid legalistic overclaims,
- avoid fake certainty.

## Review Payload

When using a configured AANA checker, send only a minimal redacted review payload:

- `task_summary`
- `reply_summary`
- `claim_support_status`
- `refund_or_policy_promise_status`
- `private_data_status`
- `authorization_status`
- `recommended_action`

Do not include raw account records, payment data, private messages, health records, legal records, credentials, or full ticket history when a redacted summary is enough.

## Decision Rule

- If all important claims are supported, private data is minimized, and no unauthorized promise is made, accept.
- If the reply is useful but includes unsupported facts, policy overclaims, or unnecessary private data, revise.
- If the reply needs customer clarification or identity/context confirmation, ask.
- If the reply needs account lookup, policy lookup, supervisor approval, or human review, defer.
- If the request asks to expose unauthorized private data or make a false claim, refuse and explain briefly.
- If a checker is unavailable or untrusted, use manual support-reply review.

## Output Pattern

For support-sensitive replies, prefer:

```text
Support reply review:
- Claim support: ...
- Refund/policy promises: ...
- Private data: ...
- Missing facts: ...
- Decision: accept / revise / ask / defer / refuse
```

Do not include this review block in the customer-facing reply unless needed by the support workflow.