fearovex/customer-issue-summary

customer-issue-summary

Transforms an already-investigated customer issue (root cause known, fix identified or applied) into a short, non-technical English summary you can paste into a Slack thread or an email reply to support / CX / ops.

Triggers: /customer-summary, customer summary, resumir customer issue, slack summary, summary for support, summary for CX

---

Purpose

Engineering investigations produce dense, technical artifacts (stack traces, logs, root-cause analyses, code references). Non-technical teammates handling the customer relationship need a much smaller artifact: what happened, who is affected, what we did about it, and what they should say next.

This skill is the bridge between those two audiences. It takes the technical investigation from the current conversation as input and produces the customer-facing summary as output. It does NOT investigate anything — the diagnosis must already exist in conversation context.

---

Process

Step 1 — Validate input

Confirm the conversation already contains:

• A clear problem statement (what the customer reported).
• A diagnosis (root cause, even if partial).
• A resolution status (fixed / in progress / blocked / monitoring).

If any of the three is missing, ask one focused question to fill the gap BEFORE producing the summary. Do not invent context.

Step 2 — Identify audience

Default audience: support / CX / ops. They will read this in Slack or forward it to the customer. They are not engineers.

Implications:

• No stack traces, no file paths, no function names.
• No internal jargon (microservice names, branch names, SDD phases).
• Action-oriented sentences in active voice.

Step 3 — Apply length budget

Hard cap: 150 words in the summary body. If the issue genuinely needs more, return one paragraph + a single bullet list (max 4 bullets) — never two paragraphs of prose.

Step 4 — Produce the summary

Wrap the output in a fenced code block so the user can copy-paste cleanly. The block contains ONLY the summary text, no preamble or commentary.

Structure inside the block:

1. One-sentence headline — what happened, in plain English.
2. Impact — who is affected, how widely, since when.
3. Action taken — what engineering did, in past tense, plain verbs.
4. Status — fixed / monitoring / pending. Mention timing if known.
5. What support can say — a one-line script the agent can use.

Step 5 — Tone

Informal English. Contractions allowed ("we've fixed", "it's working"). Calm and factual. No apologies in the body (that's CX's domain). No marketing gloss.

---

Output template

**Headline**: <one sentence, plain English>

**Impact**: <who, how many, since when>

**What we did**: <past-tense actions, plain verbs>

**Status**: <Fixed | Monitoring | In progress | Blocked>. <timing if known>

**For support**: "<one-line script for the support agent>"

The fenced block above is what you paste. Everything outside it is for you, not for the support team.

---

Rules

1. English only. The output is for international support/CX/ops teams.
2. Length cap: 150 words in the summary body. Compress if over.
3. No stack traces, file paths, function names, or internal infrastructure names. If the customer wouldn't recognize it, it doesn't go in.
4. No apologies in the summary body — that's CX's decision and tone, not engineering's.
5. If diagnosis or resolution status is missing, ASK before producing the summary. Never fabricate to fill a section.
6. Output goes inside a fenced code block for clean copy-paste. Only the summary text — no preamble like "Here's your summary:".
7. Past tense for actions taken. Present tense for current status.