AANA Ticket Update Checker Skill

Use this skill before an OpenClaw-style agent updates support tickets, GitHub issues, Linear, Jira, CRM cases, bug reports, tasks, or customer-visible status fields.

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

Core Principle

Ticket updates should be accurate, scoped, evidence-backed, privacy-safe, and authorized before changing state or customer-visible text.

Required Checks

• exact ticket, project, repository, customer, or case
• update type: comment, status, owner, priority, label, due date, escalation, close, reopen, or customer reply
• evidence for facts, reproduction steps, test results, policy claims, and status
• private data, logs, credentials, account records, and internal notes
• owner, priority, SLA, due date, and escalation authority
• whether the update is internal-only or customer-visible

Ticket Risk Classes

Treat these as higher risk:

• customer-visible comments, public issue comments, ticket closure, severity changes, SLA changes, escalation changes, and ownership transfers,
• refund, billing, legal, security, outage, incident, compliance, HR, or medical/support-related updates,
• logs, screenshots, account records, customer identifiers, internal notes, or private reproduction data,
• claims about root cause, fix status, test results, deployment status, policy, or expected timeline.

Evidence Rules

Do not update a ticket with unsupported claims about:

• root cause,
• fix shipped,
• tests passed,
• customer eligibility,
• billing/refund decisions,
• policy exceptions,
• deployment status,
• severity or priority.

Retrieve evidence or mark the update as tentative before changing status or posting externally.

Visibility Rules

Internal notes can include more diagnostic context than customer-visible replies, but still require minimization. Customer-visible updates must be concise, accurate, non-speculative, and free of internal notes or unrelated data.

Review Payload

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

• update_type
• evidence_status
• visibility_status
• privacy_status
• approval_status
• ticket_risks
• blocker_reason
• safe_alternative
• recommended_action

Do not include full logs, customer records, secrets, internal notes, or unrelated ticket history when a redacted summary is enough.

Decision Rule

• If facts and scope are clear and the update is low-risk, proceed.
• If evidence, owner, status, priority, or visibility is unclear, ask or retrieve.
• If customer-visible text or irreversible status changes are involved, require approval.
• If private data appears, redact.
• If the update is unauthorized, unsupported, or misleading, block.

Output Pattern

AANA ticket gate:
- Update: comment / status / owner / priority / close / reopen / customer_reply
- Evidence: sufficient / partial / missing / conflicting
- Visibility: internal / customer_visible / public / unknown
- Privacy: clear / needs_redaction / sensitive / unknown
- Approval: approved / required / unclear / denied
- Decision: proceed / revise / ask / retrieve / redact / request_approval / block