Generate playbooks from your codebase

One prompt for your AI coding agent — Claude Code, Cursor, Copilot or any other — that reads your repository and drafts paste-ready playbooks.

Almost everything a good playbook needs already lives in your repository: the table names, the status enums, the error strings customers paste into tickets, the retry logic wrapped around the things that actually break. An AI coding agent with your repo open can pull all of that out. What it lacks is knowing what a Triagic playbook is and what separates a good one from a vague one.

The prompt below teaches it exactly that. It works with any agent that can read your repository, against any codebase in any language, and it needs nothing from you beyond the paste — the three input lines at the top are optional.

How it works

Open your coding agent in your repository

Claude Code, Cursor, Copilot, Codex, Windsurf, Aider — anything that can explore the repo. The prompt assumes nothing about the tool.

Paste the prompt

Fill in the three optional lines if you know the answers. Leave them blank if you don't: the agent works out what it can from the code and asks for — or flags — the rest.

Paste the result into Triagic

The agent writes one labelled block per field, in the same shape as the example playbooks. Create each playbook in the portal editor or the desktop app, field by field.

The prompt

You are an AI coding agent with read access to this repository. Draft triage
playbooks for Triagic, an AI support-ticket triage tool. A playbook tells an
investigating agent how to handle one class of support ticket: how to
recognize it, what to check in which order, and which systems hold the answer.

Optional input from me (work the blanks out from the repository):
- What this product does, and who files tickets: ___
- Our most common ticket themes, if I know them: ___
- Data source names connected in Triagic (e.g. org-postgres, org-sentry): ___

## Step 1 — Learn the product from the repository

Explore before writing anything. You are looking for:
- What the product does and what its users see: README, help and marketing
  copy, UI strings, the public API surface.
- The user-visible failure domains — the distinct areas where things go wrong
  for a customer (payments, sync, sign-in, orders...). Routes, services,
  modules and background jobs are your map.
- The data model per domain: exact table/collection names, status columns and
  their enum values, and the order state moves through them.
- Error handling: user-facing error strings, retries, guards, validation
  failures, feature flags, TODO/FIXME comments, recent bug-fix commits. These
  are the known failure modes.
- Where evidence lives at runtime: the databases, log systems and error
  trackers the code actually writes to.

## Step 2 — Propose the split

Propose 3–6 playbooks, each covering one failure domain a customer would
recognize. One line of scope each. Rules:
- Split by what customers experience, not by internal architecture.
- No two playbooks may plausibly claim the same ticket. If a boundary is
  fuzzy, sharpen both scopes until it is not.
- No catch-all playbook. Unmatched tickets already get generic triage.

If you can ask me questions, confirm the split and ask — once, all together —
for anything the repository cannot tell you: ticket volume by theme, the
observability stack if it is not visible in code, data source names. If you
cannot ask, proceed on your best-supported assumptions and list them at the
top of the output.

## Step 3 — Write each playbook

Produce exactly these five fields per playbook.

Name — under 80 characters, unique.

Description — 1–2 sentences describing the class of ticket, in the words
customers use (take vocabulary from UI strings and help copy, not internal
jargon). This field routes tickets, so it must separate this playbook from
every other one. No investigation procedure here.

Routing hints — comma-separated keywords: product and feature names, exact
user-facing error strings in quotes, phrases a customer would type ("payment
failed", "order stuck"). Cover the phrasings the description misses.

Triage instructions — 150–400 words, written for a competent new hire who
does not know these systems. No persona preamble. In this order:
1. Orientation: one short paragraph on what these tickets are actually about,
   and the 2–3 distinct problems that present the same way.
2. An ordered checklist, cheapest and most-common cause first. Each step names
   the exact table/collection/index/metric to check and what each possible
   result means. Ordering is the whole value: four ordered steps beat twelve
   unordered ones.
3. Known failure modes, most to least likely, from the error handling, guards
   and fix history you found.
4. What to conclude and what to rule out: when to state "the money left us" /
   "the job completed", and what NOT to claim (one user's configuration
   problem is not an outage).
5. The out: if no check explains it, report which checks ran and what each
   returned. Do not speculate about systems you could not observe.
Include negative knowledge where the code shows it ("X is noisy and almost
never the cause").

Data sources — from the names I gave above, list only the systems this
domain's evidence actually lives in. If I gave none, write "leave unset (all
sources)" and name the systems the code suggests, so I can narrow it later.

## Hard rules

- Every identifier you cite — table, column, enum value, index pattern,
  metric, error string — must exist in this repository. Quote real names from
  real files. If you cannot verify where logs or metrics live, write the step
  conditionally ("if log search is connected: ...") instead of inventing an
  index name.
- The repository shows what CAN fail, not how OFTEN it fails. Wherever you
  rank likelihood, append "(inferred from code — reorder from your ticket
  history)".
- If one domain needs more than 400 words of instructions, it is two
  playbooks. Split it.

## Step 4 — Deliver

Write the result to triagic-playbooks.md, or print it if you cannot write
files: first a short "Assumptions & things to verify" list, then each playbook
with the five fields in labelled blocks, ready to paste into Triagic's
playbook editor field by field.

What comes back

A triagic-playbooks.md in your repo: an assumptions list to skim first, then 3–6 playbooks with Name, Description, Routing hints, Triage instructions and Data sources as labelled blocks. Each block maps to one field of the editor — creating a playbook is a paste per field.

Before you paste it in

Treat the draft as written by someone who has read your code carefully but has never been paged for it. The structure will be right; four things deserve your eyes:

Spot-check the identifiers. The prompt forbids inventing them, but a table that was renamed in an unmerged branch is exactly the kind of thing an agent gets confidently wrong.
Reorder the known failure modes. The repository shows what can fail; your ticket history shows what does. The draft marks these rankings as inferred — fixing their order is the highest-value edit you can make.
Sharpen any pair of descriptions that could claim the same ticket. Overlap makes classification a coin flip.
Run the two-run test from Anatomy of a playbook: same ticket with and without the playbook. Fewer tool calls, same answer, means it is working.

The ranking is the human part

The agent contributes identifiers, ordering candidates and coverage. What it cannot know is which failure mode generated forty tickets last quarter. That ranking — and the negative knowledge, the "this alert is always noise" — is your team's contribution, and it is what iterating on instructions accumulates over time.