Playbooks

When the code can't answer on its own, RepoHelpdesk can look things up in your database, your logs or Jira. A Playbook is the plan it writes to do that — and an admin approves it first.

• When you need one
• What a Playbook contains
• Getting it approved
• Safest option first
• Choosing how much to approve
• Reusing an approved Playbook
• When a data source is missing
• Where Playbooks live

When you need one

Plenty of support questions are really questions about live data. "Why didn't this customer get their password reset email?" The code explains how reset emails are sent, but whether one was sent to this person, and what happened to it, is in your database and your logs.

Ask anyway. If RepoHelpdesk needs a lookup to finish the answer, it says so and offers to write one.

What a Playbook contains

A Playbook is short on purpose, so an admin can read it in under a minute.

• Problem — a sentence or two on what we're trying to find out.
• Plan — each step, which data source it uses, and what that step does.
• Queries — the exact query for each step, shown in full.

Anything that changes from one run to the next — a customer's email, an order number — appears as a placeholder rather than a fixed value, so the same Playbook works for the next customer.

SELECT created_at, status, attempts
FROM PasswordResets
WHERE email = {email}
ORDER BY created_at DESC

Getting it approved

1. RepoHelpdesk proposes it in the chat

   A card appears with the problem, the plan and the queries. You decide whether to send it for approval.

2. An admin is notified

   By email and in the app, with a link straight to the chat. The email says what needs approving — never the query text or your table names.

3. They review it in the chat

   With the whole conversation around it, so the plan is read in context. If you're an admin yourself, you can review and approve it on the spot.

4. They approve, reject or improve it

   An admin who isn't happy with the plan can keep working on it in the chat until it's right. They can also talk it through with an AI first, using the same models as a normal chat.

5. It runs, and the answer comes back

   The chat picks up where it left off, now with the data it was missing.

Safest option first

RepoHelpdesk doesn't reach for your database first. It works down this list and stops at the first step that answers the question:

1. An approved Playbook that already covers it.
2. The code alone — no lookup at all.
3. A read-only lookup in a connected tool, like Jira.
4. A new query against your database or logs — which needs a Playbook.

It never calls your application's own API. Those endpoints can have side effects we can't see from the outside.

Choosing how much to approve

Reviewing every lookup gets tiring once you trust the setup. Each data source has its own setting, so you can be strict with your production database and relaxed with a log search.

Two rules hold at every level: changes to data always need approval, and an already-approved Playbook just runs. Levels only decide what happens to a new lookup. See Approval levels for the details, and Repo Map for what "let the AI decide" reads.

Reusing an approved Playbook

An approved Playbook is saved. The next time the same problem comes up — a different customer, a different chat — it runs without another approval, so the second person to ask gets their answer straight away.

Admins can list every Playbook in the project, read it, and revoke one at any time. Revoking stops it running anywhere. Changing a Playbook sends it back for approval.

When a data source is missing

Playbooks only use data sources your project has already connected. If RepoHelpdesk needs one you haven't set up, it says which, and an admin can connect it — then the chat picks up again from the original question.

If it's something RepoHelpdesk doesn't support yet, you'll be told plainly, and our team hears about the request. See Requesting a connector.

Where Playbooks live

A Playbook's queries mention your table and field names, so they're kept with your code — on the same Agent that reads your repos — not on our servers. We hold only what the notification email already carries: a title, a short description, which data source it uses, its status, and who approved it.

Two things follow from that. Your Agent has to be online to review, approve or run a Playbook, the same as for any chat. And our support team can only see a Playbook's details if you allow it — that setting is on by default, every view is logged, and the values used in a run and the rows that came back are never shown to us.