Skip to main content

summarize-a-support-ticket

Convert a long support thread into a concise, traceable case summary with customer goal, chronology, evidence, actions, and open decisions. Use when a ticket needs escalation, handoff, review, or a reliable status update.

Source facts

Repository
protosphinx/sphinxstack
Last source activity
July 29, 2026 at 13:55
Detected SKILL.md language
English
Stars
3
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
summarize-a-support-ticket
category
write
description
Convert a long support thread into a concise, traceable case summary with customer goal, chronology, evidence, actions, and open decisions. Use when a ticket needs escalation, handoff, review, or a reliable status update.
# summarize-a-support-ticket Produce a case brief that lets the next reader act without rereading the entire thread. Preserve uncertainty and link back to the original evidence. ## Inputs - Collect the complete thread, internal notes, timestamps, attachments, product telemetry, and linked incidents. - Confirm the customer, affected product or order, current owner, priority, and latest promised update. - Mark information that is customer-reported, system-observed, reproduced, or still disputed. ## Procedure 1. Write the customer's desired outcome in one sentence using their actual request. 2. Record the affected account-safe identifiers, environment, version, and time window. 3. Build a short chronology of material events, responses, tests, changes, and promises. 4. List observed symptoms separately from suspected causes. 5. Summarize troubleshooting already attempted and the result of each attempt. 6. State current impact, scope, workaround, urgency, and whether the customer is blocked. 7. List open questions, required decisions, dependencies, owner, and next checkpoint. 8. Link each important claim to the message, log, screenshot, order record, or policy that supports it. ## Boundaries Do not copy unnecessary personal data, credentials, payment details, or private internal commentary into the summary. Never present a hypothesis as a confirmed cause. Keep the original record authoritative and note where the evidence conflicts. ## Done - The summary identifies the customer goal, current impact, chronology, and latest status - Facts, customer reports, hypotheses, and unresolved questions are visibly separated - Completed actions and their checked results are listed without duplication - The next owner can act from the summary and open every cited source record
View on GitHub