ZetrixwebThe problem a support Skill actually solves
A support team's real knowledge isn't one policy - it's dozens: refund thresholds by plan tier, escalation criteria for security concerns, tone rules for enterprise versus self-serve accounts, formatting standards for different channels. Paste all of that into a single system prompt and two things happen: it becomes expensive to run on every single ticket regardless of relevance, and it becomes a merge-conflict-prone file only engineers can safely edit.
A Skill is Anthropic's answer to that: a packaged set of instructions and reference material Claude loads on demand, rather than carrying in every request. The refund-policy playbook only enters context when a ticket is actually about a refund. The security-escalation criteria only load when the conversation looks like it needs them.
What actually goes inside a support Skill
Escalation criteria
Explicit rules for when a ticket goes to a human - security concerns, legal threats, refund amounts above a threshold, or a customer explicitly asking for a person.
Policy reference tables
Refund windows by plan, SLA commitments by tier, and the specific wording legal and compliance have already approved - not paraphrased from memory each time.
Tone and channel rules
How a response should read differently in a live chat widget versus a formal email reply, and how enterprise accounts get handled differently from self-serve.
Response templates
Pre-approved language for the highest-frequency situations - a failed payment, a delayed shipment, a known outage - that legal or brand has already signed off on.
Not sure which of your current playbooks are worth packaging first? Talk to us about scoping a support Skill against your actual ticket volume.
Skills are not your ticket data or your CRM
This is the distinction that trips teams up: a Skill packages how Claude should reason and respond - the policy layer. It does not hold your actual customer records, order history, or live ticket state. That data still comes from your helpdesk (Zendesk, Intercom, Freshdesk) and CRM, typically through a separate tool call or an MCP connection Claude uses during the conversation. The Skill is the playbook; the tool connection is what fetches the specific customer's actual order.
Conflating the two is the most common design mistake in a first support-agent build: trying to make the Skill "know" customer data by hardcoding examples into it, which goes stale the moment real orders change. Keep policy in the Skill and live data behind a tool call, and the two stay correctly separated as your product and your customer base both change.
Where this fits against a plain system prompt
| Situation | Right approach |
|---|---|
| One short policy, applies to every ticket | Plain system prompt - a Skill adds overhead with no benefit here |
| Several distinct playbooks (billing, technical, security) | Skills - only the relevant playbook loads per ticket |
| Non-engineers need to update policy independently | Skills - editable without touching the application's prompt code |
| Need live order/account data mid-conversation | A tool call or MCP connection alongside the Skill, not inside it |
Rolling it out without breaking what already works
The teams that get this right don't flip a switch from human-only to AI-first support. They start by packaging the single highest-volume playbook - usually billing questions or password resets - as one Skill, run it alongside human agents with a low-confidence handoff rule, and measure resolution quality before adding the next playbook. Escalation criteria matter more early on than coverage: a support Skill that correctly hands off the 15% of tickets it shouldn't touch builds more trust than one that tries to answer everything and gets the hard 15% wrong.
Key takeaways
- A Skill packages support policy - refund rules, escalation criteria, tone, templates - so Claude loads only the relevant playbook per ticket, instead of carrying every policy in every request.
- Skills hold policy, not live data; customer records and order history still come from your helpdesk/CRM via a separate tool connection.
- A single short policy is fine as a plain system prompt - Skills earn their place once you have multiple distinct playbooks or need non-engineers editing them independently.
- Start with your highest-volume playbook, run it alongside humans with a clear escalation rule, and expand coverage only after measuring quality on the first one.