Assign incoming support tickets to the team best placed to resolve them and set priority based on customer impact. Handle cases involving two teams, and write brief internal summaries describing the problem and what the customer already tried.
How to pick the owning team and the priority for an inbound support ticket, including what to do when a ticket spans two teams. Use when triaging a ticket.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Use this skill whenever you are deciding which team owns an inbound support ticket, or what its priority should be.
billing — invoices, refunds, failed payments, plan changes, tax documents.technical_support — errors, outages, timeouts, rate limits, anything where the product is not doing what it says it does.account_management — ownership transfers, seat changes, SSO and workspace administration, renewals.product_feedback — feature requests and complaints about behaviour that is working as designed.When a ticket touches two teams, route it to the one that can close it without a handoff. A failed payment caused by an expired card is billing, not technical_support, even though the customer describes it as an error.
| Priority | Use when |
|---|---|
urgent | The customer cannot work at all, data is at risk, or money is moving incorrectly right now. |
high | A core workflow is broken for the customer but a workaround exists. |
medium | Something is wrong and it is inconvenient, but the customer can proceed. |
low | Questions, requests, and anything the customer is not blocked on. |
Plan tier never sets priority on its own. An enterprise customer asking a how-to question is low. A free-tier customer whose data is exposed is urgent.
Write the summary for the person picking up the ticket, not for the customer. One or two sentences, naming what broke and what the customer already tried.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add AI models to Kiln or find available models missing from its list. The skill checks provider model identifiers and capabilities, updates model settings, runs tests against real APIs, and drafts a Discord announcement.
Find documentation and agent instructions made outdated by a branch’s code changes. Update affected paths, commands, settings, and behavior descriptions in place, then commit the documentation fixes alongside the code in the same pull request.
Draft first replies to customers and identify tickets that require human review before sending. The skill defines sensitive cases to escalate and guides replies that explain the next action, name who handles it, and match the customer's tone.
Audit Kiln’s model list against provider APIs and catalogs to identify removed models and upcoming retirements. Get findings organized by provider, then mark affected entries as deprecated after reviewing and approving the proposed changes.
Check whether Kiln’s base models still support fine-tuning, the process of adapting a model with additional training. Compare configured identifiers and Fireworks’ allowlist with provider information, then report unsupported entries and recommend specific updates.
Apply Kiln’s coding rules when editing or reviewing Python, TypeScript, and Svelte. The skill combines area-specific guidance with a script that checks changed lines, plus manual checks for architecture, configuration handling, shared state, and asynchronous operations.