Skill: mindbomber/aana-ticket-update-checker-skill (version 1.0.0)

# 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 ```text 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 ```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)