{"skill":{"slug":"aana-ticket-update-checker-skill","displayName":"AANA Ticket Update Checker Skill","summary":"Checks ticket updates for accuracy, evidence, privacy, authorization, and risk before allowing changes to customer-visible or internal support records.","description":"# AANA Ticket Update Checker Skill\n\nUse this skill before an OpenClaw-style agent updates support tickets, GitHub issues, Linear, Jira, CRM cases, bug reports, tasks, or customer-visible status fields.\n\nThis is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or update tickets on its own.\n\n## Core Principle\n\nTicket updates should be accurate, scoped, evidence-backed, privacy-safe, and authorized before changing state or customer-visible text.\n\n## Required Checks\n\n- exact ticket, project, repository, customer, or case\n- update type: comment, status, owner, priority, label, due date, escalation, close, reopen, or customer reply\n- evidence for facts, reproduction steps, test results, policy claims, and status\n- private data, logs, credentials, account records, and internal notes\n- owner, priority, SLA, due date, and escalation authority\n- whether the update is internal-only or customer-visible\n\n## Ticket Risk Classes\n\nTreat these as higher risk:\n\n- customer-visible comments, public issue comments, ticket closure, severity changes, SLA changes, escalation changes, and ownership transfers,\n- refund, billing, legal, security, outage, incident, compliance, HR, or medical/support-related updates,\n- logs, screenshots, account records, customer identifiers, internal notes, or private reproduction data,\n- claims about root cause, fix status, test results, deployment status, policy, or expected timeline.\n\n## Evidence Rules\n\nDo not update a ticket with unsupported claims about:\n\n- root cause,\n- fix shipped,\n- tests passed,\n- customer eligibility,\n- billing/refund decisions,\n- policy exceptions,\n- deployment status,\n- severity or priority.\n\nRetrieve evidence or mark the update as tentative before changing status or posting externally.\n\n## Visibility Rules\n\nInternal 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.\n\n## Review Payload\n\nWhen using a configured AANA checker, send only a minimal redacted review payload:\n\n- `update_type`\n- `evidence_status`\n- `visibility_status`\n- `privacy_status`\n- `approval_status`\n- `ticket_risks`\n- `blocker_reason`\n- `safe_alternative`\n- `recommended_action`\n\nDo not include full logs, customer records, secrets, internal notes, or unrelated ticket history when a redacted summary is enough.\n\n## Decision Rule\n\n- If facts and scope are clear and the update is low-risk, proceed.\n- If evidence, owner, status, priority, or visibility is unclear, ask or retrieve.\n- If customer-visible text or irreversible status changes are involved, require approval.\n- If private data appears, redact.\n- If the update is unauthorized, unsupported, or misleading, block.\n\n## Output Pattern\n\n```text\nAANA ticket gate:\n- Update: comment / status / owner / priority / close / reopen / customer_reply\n- Evidence: sufficient / partial / missing / conflicting\n- Visibility: internal / customer_visible / public / unknown\n- Privacy: clear / needs_redaction / sensitive / unknown\n- Approval: approved / required / unclear / denied\n- Decision: proceed / revise / ask / retrieve / redact / request_approval / block\n```\n","tags":{"latest":"1.0.0"},"stats":{"comments":0,"downloads":337,"installsAllTime":0,"installsCurrent":0,"stars":1,"versions":1},"createdAt":1777943469626,"updatedAt":1778492846193},"latestVersion":{"version":"1.0.0","createdAt":1777943469626,"changelog":"- Initial release of the AANA Ticket Update Checker Skill.\n- Provides pre-update safety and evidence checks for support tickets, issues, cases, and customer-facing status fields.\n- Outlines required checks for ticket identity, update type, evidence, privacy, and authorization.\n- Specifies higher-risk update classes (e.g., customer-visible, billing, security, legal, and sensitive data).\n- Defines evidence and visibility rules to ensure accuracy and data minimization.\n- Introduces a concise review payload format and structured output decision pattern.","license":"MIT-0"},"metadata":null,"owner":{"handle":"mindbomber","userId":"s177cynx168hg36ac5nrkb9wdn85z9dq","displayName":"mindbomber","image":"https://avatars.githubusercontent.com/u/42798111?v=4"},"moderation":null}