Sixty Prompts for Running Support From Your Editor
The argument for connecting your helpdesk to your coding assistant has been made to death, including on this blog: an assistant that can read the ticket and the stack trace at once is worth two that can read one each. Agreed.
What nobody hands you is the list, and that is the hard part — a chat box is the least discoverable interface ever built. No menus, no buttons, nothing to hover over. You can ask anything, which in practice means you ask the same three things forever and conclude the idea was overhyped.
So: sixty prompts in the ten groups they fall into, phrased the way you would type them. Short on purpose. The density is the point — skim, steal four, and notice how much of your support week is sitting in here.
The queue
The morning look
Questions that read everything and change nothing. Where to start on a new setup, and the one group that survives a read-only key.
What needs a reply today, and is anything on fire?
Which tickets have been waiting on us the longest?
Any error group new or getting worse overnight?
Am I close to any plan limit this month?
How did email do this week — anything bouncing?
What did I miss while I was away?
Triage
Sorting, not answering. These write, but nothing leaves your account — statuses, priorities, tags and notes are all invisible to the customer.
Go through the new tickets, set a sensible priority and category on each.
Anything mentioning "charged twice" or "refund" is urgent, and category billing.
What's unassigned and older than a week?
Assign everything tagged billing to whoever handles billing.
Tickets 38 and 41 are the same bug — note that on both.
Drop the needs-triage tag from anything that has a priority now.
Answering
The part that reaches a person. Every one of these is written to put the text in front of you before it goes anywhere.
Read ticket 41, find the article that answers it, draft a reply citing it. Don't send.
Rewrite that in the tone of our last three replies to this person.
Shorter. Cut the apology and lead with the fix.
Good. Send it.
I shipped the export fix — find every open ticket about it and draft the news.
Which of these five drafts would you not send, and why?
Email, docs, and who these people are
Templates, one-off sends, and finding out what actually landed. Preview renders to nobody, so call it freely.
What templates exist here, and what variables does the welcome one take?
Show me the receipt rendered with a real order, HTML and text.
Did the receipt to jane@example.com actually arrive?
It bounced on a typo and she's suppressed now — fix that and resend.
Cancel the reminder scheduled for tomorrow morning.
Write the invoice-overdue reminder as a template, then preview it.
Knowledge base
The compounding one. Every question answered twice is an article you should have written, and the assistant just read the thread that proves it.
Turn the resolution on ticket 41 into an article — duplicate check first, leave it a draft.
What are people asking that the docs don't answer?
What have we written that's still sitting in draft?
The refund window changed from 14 days to 30 — fix every article that says 14.
Read this article against the code in this repo. What's no longer true?
Which articles get cited most in replies, and what's missing next to them?
Customers
The directory builds itself out of tickets and feedback. These prompts wire it to what your database already knows.
Who is jane@example.com, and what have we talked about before?
Read the users table in this repo and tag every customer with their plan.
Which paying customers have an open ticket right now?
Note that this one is migrating off a competitor — light touch.
Who has written in more than three times this quarter?
Who cancelled last month, and what did they say?
Errors, review, and the safety net
Errors
Your error log and your support queue describe the same bad afternoon from two directions. Crossing them by hand means two dashboards side by side, which is why nobody bothers.
Anything broken overnight?
Show me every occurrence of that fingerprint and what they had in common.
Does any error group from yesterday match a ticket someone wrote in about?
I fixed that one — mark it resolved.
Which error issues have reopened after being marked resolved?
Open a ticket for the customer who hit that error, so they hear it from us.
The review queue
Helmdesk runs six automations of its own, and most propose rather than act — drafted replies, drafted articles, log alerts. This clears what they left.
What did the automations do overnight?
Show me each drafted reply next to the ticket it answers.
Approve the ones that cite an article and are actually right; leave the rest.
Revert any auto-close where the customer wrote the last message.
Which drafted articles are worth publishing, and which are padding?
Why did it draft that? Show me what it read.
Testing safely
Every project has a sandbox plane where mail renders and is logged but never delivered, and tickets notify nobody. Rehearse anything frightening.
In sandbox: create a customer, send the welcome template, show me the render.
Now clear the sandbox so the next run starts clean.
Register a webhook for new tickets at my tunnel, then prove it works.
What did my endpoint actually answer with?
Walk the churn flow in sandbox before we point it at live.
Mint a key scoped to this project only, for the app's own .env.
Across projects
The reason one person can support five apps. One key, one conversation, and every answer says which app it came from.
Across all my projects, where is the queue worst this morning?
Which apps have gone a week without anyone answering a ticket?
Set up support for this new app — it's called Nightjar, a podcast host.
Compare error volume across every project since Friday.
Which project has the worst email delivery this month?
Which projects are still sending a different footer?
What makes a prompt work
The pattern is not subtle. The ones that work share four things.
- A checkpoint before anything leaves. Draft it, show me, then send is the difference between a tool and an incident. Ten of the tools behind these prompts reach a real person and cannot be recalled. Put the checkpoint in the sentence rather than trusting yourself to interrupt.
- A filter, not a fetch. "Which tickets have been waiting on us the longest" is one call. "List all tickets and find the oldest" is fifty. Say what you want to know, not how to fetch it.
- A judgement to make. The best ones here — which of these would you not send, which one is wrong — ask for an opinion you can overrule. That beats bulk processing, because the assistant read forty threads to form it and you did not.
- Your repo in the loop. Half of these are only interesting because your source is open at the same time. Reading an article against the code that implements it is not a helpdesk feature; it is what happens when the helpdesk turns up where the code lives.
The honest limit: at three tickets a week, typing a paragraph is slower than opening the inbox, so open the inbox. This pays off at the volume where the queue has become a thing you avoid looking at — which is exactly the volume at which you stopped noticing what was in it.
Sixty prompts is not a workflow. It is a vocabulary, and you only need six of them before the dashboard starts feeling like the long way round.
73 tools, one key, every app you run
Connect Helmdesk to Claude Code, Cursor, Codex or any MCP client, and run tickets, email, docs and error logs from the window you already have open.