Helpdesk
Your support queue in SupportCandy or Pylon, worked the way your team works it. The agent reads, sorts and drafts; a person sends every reply. A queue profile per project holds its own pulse, bug lifecycle, routines and context.
Support is a queue of people waiting on you. The helpdesk skill keeps it moving: a pulse that ranks what needs a person now, the story of any ticket, a reply drafted in your team's voice, and the bugs, feature requests and tasks behind tickets raised where your team tracks them. Ask in plain words ("what's in the support queue?", "pull ticket 318", "draft a reply for 318", "raise 318") or run it as /agent-kevin:helpdesk in Claude Code or $helpdesk in Codex.
The agent reads, sorts and drafts. A person sends every reply. It writes two things in the helpdesk: a private note, which agents see and the customer never does, so a draft or a finding waits there for someone to edit and send, and, on SupportCandy, the ticket's assignee, so the ticket reaches the person who takes it. Each waits for your yes unless a routine of yours says otherwise (Routines that don't ask). Nothing replies to a customer, changes a ticket's status or closes it.
Two steps set a queue up, and either one leads to the other:
configure-skills → Helpdesk | helpdesk setup <project> | |
|---|---|---|
| Sets up | Access: which helpdesk, a connection for each project's site or workspace (or one for no project), the keys and the tool grants | The queue: an interview that writes the project's queue profile |
| How often | Once per site or workspace | Once per project, then again to tune it |
Saying "set up helpdesk for acme-shop" starts with setup, which runs the access walk first when there's no connection it can read: none at all, or none for the project and no default. New keys load at the next session, so setup picks up after the relaunch. Keys and connections are in Configuration.
What it does
| Ask | Playbook | You get |
|---|---|---|
"What's in the support queue?", helpdesk pulse | pulse | Open tickets ranked (unassigned and longest-waiting first), patterns across them, tickets to raise, the replies your raised cards now call for, the app's App Store reviews when the profile names it, and a saved report |
"How many tickets came in today?", helpdesk stats | stats | Counts of the tickets updated in the last 24 hours (or the window you name): by status, by tag, unassigned and newly opened, for one queue or all of them |
"Pull ticket 318", helpdesk ticket 318 | ticket | The story so far: what the customer asked, what support said, internal notes apart, who's who, what's still open |
"What's open for Acme?", helpdesk account acme | account | One customer company's tickets (Pylon) |
"Draft a reply for 318", helpdesk draft 318 | draft | A reply in your queue's tone, left as a private note once you approve it |
"Any App Store bug reports?", helpdesk reviews | reviews | New App Store reviews read for bugs at every star rating, each bug gathered with its cards, tickets and older reviews into one card, or a comment on the card already open. App Store reviews |
"Raise 318", helpdesk raise 318 (helpdesk bug 318 for a bug) | raise | The ticket as a bug, a feature request or a task, wherever your profile sends that kind: a task, or a GitHub card with the repro, a log excerpt and the screenshots |
"Set up helpdesk for acme-shop", helpdesk setup acme-shop | setup | Access first when there's no connection it can read, then the interview that writes or tunes its queue profile |
A routine your profile defines, helpdesk digest | workflow | Whatever that routine's steps produce |
Tickets come back with the people on them: the customer, the assignee, and each message's author, with names and emails where the helpdesk gives them. That's how the agent finds the account, reads the history and answers by name. They stay in your home: a GitHub card links the ticket instead of copying anyone's contact details.
A queue profile
Each support queue gets a profile in the project its tickets belong to: projects/<slug>/helpdesk.md. The plugin ships a default workflow. A profile changes it for that queue, and nothing in the plugin needs to change.
---
connection: shop
statuses: [Open, Awaiting agent reply]
schedule: [pulse:daily, digest:weekly]
---
## Pulse
Feature requests are counted, not listed.
## Bug lifecycle
| State | Means | Support's part |
|---|---|---|
| triage | Raised, not looked at yet | Nothing |
| needs info | Development asked the user something | Draft the question as a reply |
| closed as completed | Fixed in the release on its milestone | Draft "it's fixed" for every ticket on the card |
## Raising
Bugs and tasks go to a card on acme/app labelled triage; feature requests are counted, not raised. No location in a log or a screenshot.
## Tone
Warm and short. Money questions are answered by a person.
## Context
The app is on 4.2. Help docs: https://help.acme.test
## Workflow: digest
1. Count this week's tickets by topic for the team, with the three most asked.The frontmatter is read by code:
| Key | Means |
|---|---|
helpdesk | supportcandy or pylon, needed only when both are configured |
connection | A named connection; leave it out for the default |
statuses | Required: the statuses the pulse treats as open |
schedule | <routine>:<daily|weekly|monthly> entries. Sync nudges each one when it hasn't run in its period |
appstore | The app's App Store id; the pulse and helpdesk reviews then read its reviews, and sync counts them (App Store reviews) |
storefronts | Optional countries to pin that read to; left out, the reviews tool picks them |
The body is read by the agent, in your words:
| Section | Effect |
|---|---|
## Pulse | Adds to the default pulse, or replaces it when its first line is Replaces the default. |
## Bug lifecycle | Replaces the default lifecycle: what each state of a raised card or task means and what support does about it |
## Raising | Where a bug, a feature request and a task each go: a task, a GitHub card and its labels, or nowhere. A kind it doesn't name goes where bugs go |
## Workflow: <name> | A routine of the queue's own, run as helpdesk <name>. Its steps can say its notes and assignments go ahead without asking |
## Triage, ## Tone, ## Context | Rules and facts every playbook reads |
An organisation's own plugin can ship rules of its own beside the skill (skills/helpdesk/references/org.md): defaults, plus boundaries no profile can loosen.
The interview
You don't write the profile by hand. helpdesk setup interviews you in six rounds, shows the default at each step, and takes "the default" as an answer:
- The queue: the project, the connection, which statuses count as open, how often the pulse runs, and the app's App Store link if it has one.
- The pulse: what needs a person first, what to collapse into a count, what else to check, who reads it.
- Raising: where bugs, feature requests and tasks go, the lifecycle (starting from the default), what a card carries and never carries.
- Replies: tone, language, sign-off, what is never promised, what a person writes.
- Context: the product and its versions, help links, known issues, the team, escalation.
- More routines: a weekly digest, a review sweep, anything else recurring, and whether each one's notes and assignments go ahead without asking.
Run it again to tune one part: it shows what the profile holds and changes only the rounds you pick. A seed bundle carries the profile with the project, so a teammate's agent starts out knowing the queue.
The default bug lifecycle
| State | Means | Support's part |
|---|---|---|
triage | Raised, not looked at yet | Nothing |
needs info | Development asked the user something, on the card | Draft the question as a reply; once the user answers, add it to the card |
accepted | A real bug that will be fixed, or work the team will do | Nothing |
in progress | The fix or change is being written | Nothing |
| closed as completed | Done, in the release named by its milestone | Once it's out, draft "it's fixed" (or "it's out") for every ticket on the card |
| closed as not planned | Not a bug, or not doing it | Draft a reply that explains the decision |
The pulse works through every state where support has a part, so a question from development or a shipped fix turns into a draft without anyone chasing it. A raised card names its ticket in its title ((ticket 318)), which is how the pulse matches the two; a card raised from App Store reviews lists the rest of its tickets in its body. Development moves the card along: the engineer skill offers to swap accepted for in progress when it starts building, and to set the milestone to the release the fix ships in when it's done. The fix's commit or PR says Fixes #<n>, so GitHub closes the card when it lands. A closed card whose milestone hasn't been released yet is fixed but not shipped, and the pulse waits for that version before drafting "it's fixed".
Routines that don't ask
Every write waits for your yes by default. A routine can lift that for its own private notes and assignments, so a sweep that reads each new ticket, leaves a note and hands the ticket to a person runs without a yes per ticket:
## Workflow: sweep
1. Every Open ticket that's unassigned gets a private note and is assigned to Ada. Write the notes and assign the tickets without asking.
2. A ticket with no text of its own: read the attached log. The note's first line says "Look at this" or "Safe to archive", and why.
3. End with a summary: how many tickets, the ones to look at, and the ones safe to archive.The routine's output lists every ticket with what was written. Cards, tasks and comments still wait for a yes, and nothing replies, closes, archives or changes a status. Assigning needs the agent role's Assign Agents for that kind of ticket (Helpdesk pack); Pylon tickets can't be assigned yet. SupportCandy's API has no archive call, so archiving stays with a person: a routine lists the tickets to archive, and the list is one bulk action in SupportCandy.
Pulses on a schedule
A routine in schedule shows up in sync's cadence block when it hasn't run in its period, as helpdesk pulse acme or helpdesk digest acme. Sync only nudges: a pulse reads customer text against rate limits that suit a person asking, not an unattended run. Each complete run of a scheduled routine saves a report to reports/helpdesk/ (one cut short by an error saves nothing), and the newest one is what tells sync it ran.
Sync does count every queue itself, in a 🎫 Support block: tickets updated in the last 24 hours by status and tag, unassigned, and newly opened. The count reads no ticket text, so it's safe to run unattended. It covers each project's profile, then each connection no profile reads, so a no-project connection or a project whose setup hasn't run still shows up. Without a profile, Pylon counts its open statuses and SupportCandy counts every status. helpdesk stats shows the same counts on demand.
A profile with an App Store app gets a reviews line under its ticket counts: the last 24 hours' reviews by star, every star shown. When reviews arrived since the last complete read, sync offers helpdesk reviews acme. Both reads ask for counts only, so sync never reads a review's text.
Tax and books
Know what tax you owe at every moment, for your companies and your personal return. Every obligation becomes a dated task, receipts land in one ledger, the month closes for your accountant, and the estimate is planned before the penalty, not after.
App Store reviews
Any app's App Store reviews, newest first, from Apple's public feed. No key and read-only; the agent never replies to a review. In a helpdesk queue, the bugs they report become cards beside its tickets.