support-brief

What this skill does

# 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 th