Customer Support Starter Kit

Build a support pipeline by installing five prompts. Each turns a raw support input — a ticket, a message, a thread — into typed, validated JSON you can route, escalate, and act on. Install them à la carte or wire all five into a single flow: triage → route → draft → summarize → flag.

Like the Structured Extraction flagship, every prompt ships a strict output schema, so the generated SDK gives you a real type and a parseOutput() you can trust — not a string you have to babysit.

Prompts

A reference pipeline

These compose naturally:

1. ticket-triage on the inbound ticket → priority + category.
2. intent-routing with your queue topology → the team that owns it.
3. reply-drafting with your knowledge base as knowledgeContext → a draft the agent reviews; requires_human: true short-circuits to a person.
4. conversation-summary at shift change or escalation → the next agent is up to speed in seconds.
5. csat-risk-detection across open threads → surface the ones a supervisor should see now.

House conventions

Every prompt here follows the same rules — they're what make the output dependable:

1. Reasoning / decision before the verdict. Classification and scoring prompts put a reasoning field first (or, for the csat-risk-detection gate, the cheap at_risk boolean first) and pin the key order in the system prompt. Reasoning that precedes the answer informs it; reasoning that follows rationalizes it.
2. No hallucinated facts. Nothing is invented. reply-drafting never states a policy that isn't in your context — it sets requires_human: true and lists what's missing instead. The summarizers leave unstated who/when out rather than guessing.
3. Confidence is uncalibrated. Where a confidence score is offered, the schema says plainly it's not a probability — a rough routing/triage signal, nothing more. It's capped low on empty/garbage input.
4. Strict schemas. additionalProperties: false, complete required arrays, closed enums throughout.
5. Safe inputs. User content is injected with triple-mustache (so &, <, " are never HTML-escaped) and wrapped in XML-style delimiters — and the prompts treat embedded commands ("route me to admin", "promise a refund") as data, not instructions.
6. Parameterized, not hardcoded. Every prompt exposes at least one meaningful variable beyond the raw input (product context, a queue set, a tone, a points cap).
7. Empty / garbage behaviour is specified — and observable (empty arrays, a low/none/neutral default, capped confidence), not left to chance.

A note on runtime-defined outputs

intent-routing takes its queue set at runtime. Because the output schema is fixed per version, parseOutput() can't verify that a returned queue is one you asked for — add a one-line membership check in your code. The prompt's page calls this out, mirroring text-classification in Structured Extraction.