Super Magic Skills & Use Cases
New to Skills? Check out everything you need to know about creating Super Magic Skills here:
More Skills & Use Cases Are Coming π
Weβre just getting started. More tested Skills and real-world use cases will be added over time, so check back regularly for new additions.
In the meantime, donβt hesitate to ask Super Magic to help you create a Skill for your own workflow. Whether youβre automating repetitive tasks, preparing for meetings, or streamlining your day-to-day, Super Magic can help you build a custom Skill tailored to your needs.
The Skills below have been tested against real ticket data and are ready to use.
Three full Skills you can copy in right now
These three are the meeting-prep Skills built for service management. They've been tested against real ticket data and are designed to be pasted into Super Magic as-is, with a couple of bracketed values swapped in.
Skill 1 β One-on-One Prep
Who runs it: service managers, monthly, per engineer.
What it gives you: a five-paragraph, under-300-word candid brief on ticket load, response and resolution patterns, and client sentiment β the kind of read that anchors a real conversation instead of a "how's it going."
"Prepare a one-on-one prep summary for [Engineer Name] covering the past month (last 30 days). This is for the service manager's use only, ahead of a status check-in meeting, so be direct and candid. Review:
- Ticket load and completion: how many tickets they worked, opened vs closed, and note anything still open or aging that's worth flagging. This is a holistic look, not a strict volume target. If a query hits a result cap and the true count is uncertain, say so explicitly rather than presenting an estimate as exact.
- Response and resolution time: how they're tracking on time-to-first-response and time-to-resolution across their tickets this month, and call out any pattern of slow response or resolution if one exists.
- Client sentiment: pull Thread's sentiment analysis across their tickets this month and note anything notably positive or negative.
Close with two short sections: a couple of standout highlights (can come from any of the above, including technical approach or client communication even if not explicitly listed), and a couple of areas to improve.
Write in tight narrative prose, 5 paragraphs total, no more than 300 words combined. Synthesize and summarize rather than enumerating every ticket. Only name a specific client or ticket if it genuinely needs the manager's attention or action; everything else should be described in aggregate (e.g. 'the rest closed within a day or two with no issues'). Skip ticket links and IDs entirely."
Skill 2 β QBR Prep
Who runs it: account managers, quarterly, per client.
What it gives you: a 600-word, section-headed internal brief covering ticket volume, top recurring issues, long or high-effort tickets, sentiment trends, and opportunities for a project or training engagement. It's tuned to surface the things a client won't bring up themselves.
"Prepare the QBR (quarterly business review) prep report for [Client Name], covering the past 3 months. This is for the account manager's use in preparing meeting notes and talking points ahead of the client check-in, not something to hand to the client directly.
Open with a brief overview: total ticket volume for the period, opened vs closed, and a general sense of the client's overall support activity level. If the true ticket count can't be determined precisely because the volume exceeds what a single query can return, say so plainly and give your best order-of-magnitude estimate rather than presenting a specific number as exact, and don't try to reconcile it against a prior run.
Then cover, with light section headers so this can be scanned quickly:
- Recurring issues: identify the top 4β5 recurring patterns only, ranked by how much they matter (frequency, client impact, or technician time consumed), not every pattern that exists. For each, state how often it occurred, describe it in one to two sentences, and give exactly one representative example described in plain language (no ticket IDs). Do not list every affected user or asset.
- Long or high-priority tickets: identify the top 5 tickets from the period that either took a long time to resolve or consumed significant time/effort, regardless of current status. Present as a short prose list, one line each, no tables, no ticket IDs. Note whether each is a 'sat open a long time' case or a 'high effort' case.
- Client sentiment: overview of sentiment trends across the client's tickets this period, including any notably low scores and what drove them, described in plain language without ticket IDs.
- Opportunities: flag areas where a project, infrastructure update, or user training could reduce ticket volume or improve client experience, including recurring requests that suggest the client is hitting a limitation of their current setup.
Throughout, pay particular attention to issues or patterns the client is unlikely to bring up themselves. This report has a hard limit of 600 words. Prioritize signal over completeness β if you have to choose between covering all four sections briefly or covering fewer sections in depth, cover all four. Do not include ticket ID numbers anywhere in the report. Format this as a report the account manager can scan quickly before the meeting, not a compressed narrative summary."
Skill 3 β Client Health Scan
Who runs it: service delivery leadership, monthly, across all service boards.
What it gives you: a ranked list of 5 clients (up to 10 with genuine ties) showing the strongest combination of risk signals, each with a "why flagged," "evidence," and "suggested next step." Designed to anchor the first 10 minutes of a monthly service delivery meeting.
"Run a client health scan across the [Board 1], [Board 2], and [Board 3] boards, covering the past 30 days. This feeds our monthly service delivery meeting, so the goal is to surface clients who may be at risk before it becomes a bigger problem, not to review every client in detail.
To avoid missing activity from earlier in the 30-day window due to result caps, run separate targeted searches per board for each of the four warning signs below, rather than one general pull of recent activity:
- Low or declining sentiment scores
- Aging or 'no response' tickets
- Recurring issues without an identified root cause
- Unresolved Priority 1 or critical-severity tickets, regardless of age or whether they're part of a recurring pattern. A single unassigned or unresolved P1 is a risk signal on its own, even as an isolated event.
If any individual search still hits a result cap, say so explicitly in your methodology note rather than presenting the data as complete.
Rank and select the 5 clients showing the strongest combination of these signals across all boards. A client with an unresolved P1/critical ticket should be flagged even if it doesn't show up as a recurring pattern or in the other three signals. If there are genuine ties or borderline cases at the cutoff, extend the list up to 10 rather than forcing an arbitrary cut. Don't flag a client based on ticket volume alone β the concern here is risk signals, not raw activity level.
Open with a brief summary: how many clients were reviewed across the boards, and how many were flagged this month. Then for each flagged client, provide three separate labeled parts:
- Why flagged: which of the four warning signs applied and a brief explanation
- Evidence: a short narrative summary of the supporting tickets or pattern, with a representative example or two. Ticket IDs aren't necessary β describe the issue in plain language.
- Suggested next step: a brief, concrete recommendation the team can use as a starting point for discussion (e.g. account manager outreach, a technical review, a proactive fix).
Keep each client's entry concise β this is meant to guide a live discussion, not replace it. Close with a brief methodology note: how many threads were reviewed per board, and whether any search hit a result cap that may have limited coverage of the full 30-day window."
Skill 4 β Quality Assurance
Who runs it: Service desk technicians, team leads, or anyone responsible for ticket quality before closure.
What it gives you: An automated QA review of the ticket against four closure requirements. If all checks pass, the ticket is closed automatically. If any check fails, the ticket is re-opened and an internal note is added detailing exactly which checks passed or failed and what needs to be corrected.
"Review the ticket's full conversation and notes. Check all 4 criteria:
1. Customer issue was genuinely resolved (dismissive/hostile responses don't count)
2. Ticket type, subtype, and item are set
3. A technician is assigned as owner
4. A time entry was submitted
**QA Passed (all 4 met):** Set status to >Closed.
**QA Failed (any missed):** Do both steps in order:
- Set status to Re-Opened
- Add an internal note in plain text only (no Markdown, tables, bold, emojis, or symbols) using this exact format:
QA Failed - Action Required:
- PASS/FAIL: Customer issue resolved: [explanation]
- PASS/FAIL: Ticket type, subtype and item set: [explanation]
- PASS/FAIL: Technician assigned: [explanation]
- PASS/FAIL: Time entry submitted: [explanation]"
