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 th