Prompt cookbook

Give me today's picture for Ledgerly: what needs a reply, and is anything on fire?

One call, one snapshot: tickets by status, how many await a reply and how many of those have gone stale, tickets resolved this week, open error issues and log volume over 24 hours, email delivery for the week, feedback and average rating, and how many agent actions are waiting on you.

This is the cheapest useful prompt in the whole cookbook. It replaces about six list calls.

Which tickets have been waiting on us the longest?

Tickets filtered to those awaiting a reply, oldest first. Each row carries who sent the last message and when, so "waiting on us" is a real answer rather than a guess from the status field.

Am I close to any plan limit?

Every meter against its limit: tickets, emails, log events and retention, storage, agent runs, projects, team members, plus the period it resets. A limit of -1 means unlimited.

Anything broken overnight? Show me error groups that are new or getting worse.

Grouped error issues, one per fingerprint, with occurrence count and first and last seen. Thousands of near-identical events collapse into a handful of real problems.

How did we do on email this week — anything bouncing?

The delivery log with status per send, and the list of addresses the project will no longer email, with the reason each one was suppressed.

Go through the new tickets. Anything mentioning "charged twice", "double charge" or "refund" is urgent and category billing. Everything else, set a sensible priority and tag it.

Each ticket read, classified, and updated. The agent tells you what it decided and why, ticket by ticket.

update_ticket only emails the customer when you set status to resolved. Changing priority, category or assignee sends nothing.

Assign everything tagged billing to whoever handles billing on the team.

The team list first, because assignment needs real user ids, then one bulk call covering up to 100 tickets with a per-ticket report of what was updated, skipped, or failed.

Reassigning emails nobody. The same tool asked to resolve a batch would send a satisfaction survey to every customer in it — which is why it is marked as reaching a customer even though this use does not.

Ticket 41 is the same bug as ticket 38. Note that on both and leave a summary of what I found.

A staff-only note on each thread. Never emailed, never shown on the customer portal, and it does not move the status.

This is the tool to reach for when you want to record something without talking to anyone. It is the safe counterpart to reply_to_ticket.

What is unassigned and older than a week?

The unassigned filter takes the literal string "unassigned", so this is one call rather than a fetch-and-filter.

Remove the needs-triage tag from anything that now has a priority set.

Tag removal is idempotent — a ticket that never had the tag is a no-op rather than an error, so this is safe to re-run.

Read ticket 41, find the article that answers it, and draft a reply citing it. Do not send — show me first.

The full thread, the matching article, and a drafted reply in the conversation. No tool call goes out to the customer.

There is no "draft" tool. The draft lives in your chat until you say send, which is exactly the checkpoint you want.

Good. Send it.

The message is posted to the thread as staff and emailed to the customer immediately with a link back to the conversation. A ticket in status new becomes open.

This cannot be unsent.

I just shipped the fix for the CSV export bug. Find every open ticket about it, reply telling them it is live, and resolve them. Show me the replies first.

One reply per ticket, written from the actual fix rather than a template, then each ticket resolved.

Resolving emails each customer a satisfaction survey on top of your reply. That is two emails per person — usually what you want, occasionally not.

Answer this in the same tone as the last three replies we sent this customer.

The customer record carries their full ticket and feedback history, so the agent can read how you have spoken to this person before rather than inventing a house voice.

What templates does this project have, and what variables does the welcome one take?

Project templates and account-wide shared ones, then the exact variable names the chosen body references — so nothing is guessed when it comes to sending.

Show me the welcome email rendered with my name, as HTML and as text.

The rendered output, twice. Nothing is sent and nothing is written to the email log.

Write a template for the invoice-overdue reminder, then preview it before we use it anywhere.

A new template created from Handlebars source, then rendered. Importing against an existing key creates a new version rather than overwriting.

Send a one-off note to jane@example.com explaining the outage and what we did about it.

A subject and Markdown body written on the spot, wrapped in the project layout. Preview first, then send.

For anything you will send more than once, make it a template instead. Custom email is for the genuinely one-time message.

Did the receipt to jane@example.com actually arrive?

The send, and then its full event timeline — queued, sent, delivered, opened, bounced, complained — plus the variables it was rendered with and why it was blocked if it was.

It bounced because of a typo. She is on the suppression list now — fix it and resend.

The suppression removed so mail can flow again, then a fresh send to the original recipient through the gateway.

Cancel the reminder scheduled for tomorrow morning.

The scheduled send is cancelled. Anything already sent returns a 409 rather than pretending to recall it.

Turn the resolution on ticket 41 into a help article. Leave it as a draft and check we do not already have one.

A search first so you do not dilute results with a duplicate, then a draft article in Markdown. Drafts are invisible to the public help centre and to widget answers until published.

create_article defaults to draft. Publishing is a deliberate second step.

What have we written that is still sitting in draft?

The management view, which includes drafts. search_articles only ever sees published articles, so this is the one that answers "what did I forget to publish".

Look at the last month of tickets. What are people asking that the knowledge base does not answer?

A gap list, grounded in real threads rather than in what you imagine people ask.

The built-in KB Gap Analysis agent does this on a schedule and files drafts into the review queue. This is the on-demand version.

The refund window changed from 14 to 30 days. Fix every article that says 14.

Each affected article found and revised. The body replaces rather than merges, so the agent reads before it writes.

Who is jane@example.com and what have we talked about before?

The profile plus full ticket and feedback history in one call. Lookup works by email or by your own user id.

Read the users table in this repo, then tag every Helmdesk customer with their current plan.

Tags synced from your own database. set_customer_tags can replace a single namespace and leave the rest alone, so plan tags update without disturbing anything you tag by hand.

That namespace behaviour is what makes this safe to run on a schedule rather than once, carefully.

Which paying customers have an open ticket right now?

Tag filters are ANDed, so a segment like "paying and on the gold plan" is one call rather than a client-side intersection.

Add a note that this customer is migrating from a competitor and needs a light touch.

A staff-only internal note on the profile. Visible to your team through the API and dashboard, never to the customer.

Any error group from the last day that matches a ticket a customer has already written in about?

The overlap. This is the awkward question that never gets asked by hand because it means holding two dashboards side by side.

Show me every occurrence of that fingerprint and what the requests had in common.

Every raw event in one error group, filtered by fingerprint, with the structured metadata each one carried.

I fixed that one. Mark it resolved.

The issue is resolved rather than deleted, and reopens automatically if the error recurs — which is the point.

Prefer this to delete_log_issue. Deleting throws away the history that would tell you the fix did not hold.

Open a ticket for the customer who hit that error, so they hear it from us first.

A ticket opened on the customer’s behalf. Staff are notified; the customer is not emailed by this call.

What did the agents do overnight?

Everything pending a human: drafted replies, drafted articles, auto-closed tickets, log alerts, email-health findings.

Show me each drafted reply next to the ticket it answers. Approve the ones that cite an article and are actually correct; leave the rest for me.

A review pass with the evidence attached, rather than approving a list of summaries.

Approving a drafted reply is what posts and emails it. Approval is the send button.

Revert any ticket auto-close where the customer wrote the last message.

Each wrongly-closed ticket reopened. Auto-Close acts rather than proposes, which is exactly why it is revertible.

Test the whole welcome flow in sandbox: create a customer, send the welcome template, and show me how it rendered.

The full pipeline exercised end to end. The send is captured with status sandboxed, so you can read exactly what would have arrived.

You do not need a second key. A live key can send one call to sandbox, or set HELMDESK_ENVIRONMENT=sandbox for the session.

Now clear the sandbox so the next run starts clean.

Every sandbox ticket, customer, send, feedback item and log event removed. Templates, layouts and articles survive, because those are what you promote to live.

Irreversible, but only ever touches sandbox. It cannot reach live data whatever key you hold.

Register a webhook for new tickets pointing at my relay, then prove it works.

The endpoint registered, a synthetic ticket.created delivered to it, and the exact status, body and duration your server answered with.

The signing secret comes back only in the create response. test_webhook reaches your own endpoint, never a customer.

Across all my projects, where is the queue worst this morning?

One overview per project, ranked. Every response object carries projectId and projectSlug, so there is never any doubt which app a number belongs to.

Which apps have gone a week without anyone answering a ticket?

The neglected ones. This is the question that catches the side project you forgot had customers.

Set up Helmdesk for this new app. It is called Nightjar, a podcast host.

A project, a key scoped to just that project for the app’s own .env, and the widget snippet with the real slug in it.

Walked through step by step on the scaffold page. Needs projects:manage and api_keys:manage.