fearovex/support-brief

support-brief

Transforms an already-investigated customer issue (root cause known, fix identified or applied) into a short, non-technical engineering-to-CS brief — one natural message, led by the finding, that you paste into Slack for the support team.

Triggers: /support-brief, support brief, brief for support, resumen soporte, brief for CS

---

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.

Verify before asserting — the overriding rule. A brief states ONLY what is confirmed against real data (Stripe, logs, DB). If a cause was not verified, write it AS an inference ("likely the bank is blocking the recurring charge"), never as a fact. Real example: a brief said "genuine card problem" as fact; the Stripe check showed transaction_not_allowed — the bank blocks the recurring charge, the card is not dead. The verified version is both more precise and more actionable. Only open with "I checked this in Stripe" when you actually did.

---

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.

Then ask: does this even warrant a brief? If the case was NOT reported by the customer AND does not affect them (e.g. an internal data field out of sync, invisible to the user), do NOT produce a per-customer message. Note it in the technical tracker and stop. A brief exists to inform support about something a customer feels — not to narrate an invisible internal cleanup.

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. They answer each customer separately and decide their own next steps — the brief gives them INFORMATION, not instructions.

Implications:

• No stack traces, no file paths, no function names.
• No internal jargon (microservice names, branch names, SDD phases).
• Active voice, but never imperative aimed at support ("you should…", "make sure to…"). Facts, not directives — see Step 6.

Step 3 — Apply length budget

Hard cap: 120 words in the summary body. One natural paragraph. No headers, no bullet lists, no sections — those turn a message into a form. If you can't fit it in one paragraph, you are including detail the CX teammate doesn't need.

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.

Write ONE single message addressed directly to the CS teammate. Engineering and CS share full transparency, so this IS the message CS reads — there is no separate "what to tell the customer" line. CS decides for themselves what to relay. Write it as natural prose (not labeled fields).

Voice: first person by default. When the person writing the brief is the same person who investigated and fixed it, write "I" ("I checked this in Stripe", "I shipped a fix"). Only use "we" when a real team did the work. NEVER invent an "engineering team" / "the team will look into it" if no such team exists — that attributes the work to a subject that does not exist and breaks the brief's trust.

Lead with what the investigation ADDS, not with the symptom CS already has in the ticket. Order the message as:

• The finding first — root cause and real scope ("the discount has gone missing on the payments side… for anyone who reaches that step, not just him").
• The symptom only as a brief anchor so CS knows which ticket this is, never as the opening beat.
• What's happening or what's next, plus any open question CS still needs answered ("I still need to confirm whether his subscription ended up canceled").

If the brief mentions a bug, it MUST explain what the bug was — in plain language a non-technical reader can understand and relay. "There was a bug on our side" with no explanation is unacceptable. Describe the MECHANISM in terms of observable behavior, never function or file names: "when someone reactivated, the system turned off their old plan before confirming the new payment".

One brief per customer. If several customers share the same root cause but hit different outcomes, produce N individual briefs — one per account, adapted to what happened to THAT customer — because support answers each customer separately. A single group message is the anti-pattern here.

Only include facts relevant to THIS context. Omit anything CS wouldn't act on. Relevance beats completeness.

Step 6 — Inform, never instruct

The brief delivers FACTS, at most a SOFT suggestion explicitly marked optional ("that's your call", "if you want, I can…"). NEVER a directive ("best next step is to…", "you should…", "make sure to…"). Support decides what to tell the customer. Transparency means sharing everything you found — it does NOT mean telling support what to do with it. Transparency ≠ instruction.

Step 7 — Tone

Informal English, like a quick Slack message to a teammate. Contractions allowed ("I've found", "it's erroring"). Calm and factual. No apologies in the body (that's CS's domain). No marketing gloss. No engineering jargon.

---

Output shape

One fenced block. Inside it: one natural message in plain prose addressed to the CS teammate. No labels, no headers, no separate "for support" line. It opens with the finding, not the symptom.

Example (a retention discount went missing on the payments provider):

Heads up on [email protected]: the 50%-off discount we offer members during
cancellation has gone missing on the payments side, and that's what's erroring
out for anyone who reaches the discount-offer step, not just him. On his cancel
attempt the screen threw that error, so he assumed it didn't go through and
tried a few more times. I'm checking why it was removed and which discount
should be in place before I put it back. I still need to confirm whether his
subscription ended up canceled or is still active.

The fenced block is what gets pasted to CS. Everything outside it is for the engineer, not the CS team.

---

Rules

1. English only. The output is for international support/CX/ops teams.
2. Length cap: 120 words. One natural message. 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 CS'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 gap.
6. Output goes inside a fenced code block for clean copy-paste. Only the summary text — no preamble like "Here's your summary:".
7. Never propose an unverified fix. State only what is confirmed. When the root cause is known but the solution is not, say what we're finding out (e.g. "we're checking why X happened and what should replace it"), NOT what we'll do. Do not promise a fix, a timeline, or a specific change that hasn't been decided. A guessed solution in a CX message becomes a broken promise.
8. One message, not a form. No labeled fields (Headline/Impact/Status) and no separate "for support" / "what to tell the customer" line — CS and engineering share full transparency, so the single message IS what CS reads and CS decides what to relay. Write prose a teammate would actually send in Slack. Relevance over completeness — omit any fact CS can't act on. If something is still unconfirmed, say so plainly as an open question. Transparency ≠ instruction: share everything you found, but never tell support what to do with it.
9. Lead with what the investigation ADDS, not with the symptom CS already has. CS already has the customer-reported symptom in the ticket — do not re-narrate it. Open with the finding: root cause, real scope, what's happening, the open question. The symptom appears only as a brief anchor so CS knows which ticket this is ("on his cancel attempt…"), never as the opening beat.
10. Verify before asserting. State only what is confirmed against real data (Stripe, logs, DB). Unverified causes go in as inferences ("likely…"), never as facts. Open with "I checked this in Stripe" ONLY if you actually did.
11. First person by default. When the writer is the one who investigated and fixed, write "I". Use "we" only for a real team. NEVER invent an "engineering team" / "the team will look into it" that doesn't exist — don't attribute work to a non-existent subject.
12. Inform, never instruct. Facts, at most a soft suggestion marked optional ("that's your call", "if you want, I can…"). NEVER a directive ("you should…", "best next step is…", "make sure to…"). Support owns the next step.
13. If you mention a bug, explain what it was — plain-language mechanism in terms of observable behavior, no function or file names. "There was a bug on our side" alone is unacceptable.
14. No brief for non-problems. If a case wasn't customer-reported AND doesn't affect the customer (invisible internal data desync), don't fabricate a per-customer message — log it in the technical tracker instead.
15. One brief per customer. N affected customers with the same cause but different outcomes → N individual briefs, each adapted to that account. A single group message is the anti-pattern — support answers each separately.