Starter Writing skill
Summarize a support ticket
Convert a long support thread into a concise, traceable case summary with customer goal, chronology, evidence, actions, and open decisions.
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
- Write the customer's desired outcome in one sentence using their actual request.
- Record the affected account-safe identifiers, environment, version, and time window.
- Build a short chronology of material events, responses, tests, changes, and promises.
- List observed symptoms separately from suspected causes.
- Summarize troubleshooting already attempted and the result of each attempt.
- State current impact, scope, workaround, urgency, and whether the customer is blocked.
- List open questions, required decisions, dependencies, owner, and next checkpoint.
- 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.
--- 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