What the agent does
Your help desk receives a ticket and your backend starts one run for it: the repository in resources, the customer's question in input. The agent clones the code into its own cloud sandbox and answers from the Go source, not from the docs site. In a PocketBase codebase like pocketbase/pocketbase, it sees from go.mod that the module is github.com/pocketbase/pocketbase, finds the record routes registered under /collections/{collection}/records in apis/record_crud.go, and the shared list and search logic in tools/search/provider.go.
For the ticket "why does a list request return only 30 records when I asked for 500?", the agent follows the request from the route to the query. recordsList in apis/record_crud.go builds a search.NewProvider and hands it the raw URL query through ParseAndExec. In tools/search/provider.go, Parse reads exactly five parameters by their constant names: page, perPage, sort, filter and skipTotal. The provider starts with perPage set to DefaultPerPage, which is 30, and Exec clamps any value above MaxPerPage, which is 1000. So 500 is allowed, and a page of 30 means the server never saw a perPage of 500.
That points to the request, and the agent says which mistakes produce it. url.ParseQuery and params.Get match names exactly, so limit=500, per_page=500 or perpage=500 are all ignored and the default of 30 applies. A value that is not an integer makes strconv.Atoi fail and the whole request returns a 400, not 30 items, which rules that case out. The agent also notes the two server-side places that could change the answer: an OnRecordsListRequest hook (declared in core/app.go) that a project's own Go or JS hooks can use to rewrite the result, and the collection's ListRule, which filters rows before pagination and can make fewer rows exist than the customer expects.
It then writes the reply the prompt asks for: two short paragraphs a customer can read, the files and line ranges that prove each claim, and a confidence level. It changes no code. Where more than one cause fits, the answer names the check that tells them apart, here the perPage field in the JSON response, which echoes the value the server actually used.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A customer asks: why does a list request return only 30 records when I asked for 500? Find the answer in this repository's code, not its docs: start at the records list route in apis/record_crud.go and follow the query string into Parse and Exec in tools/search/provider.go. Say which parameter names are read, what the default and maximum page sizes are, and whether a hook or a list rule could change the count. Reply with JSON: answer (two short paragraphs a customer can read), files (paths and lines that prove it), and confidence. Do not change code.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is the agent's final answer, the JSON object the prompt names. answer tells the customer in plain words that the page size parameter is perPage, spelled exactly that way, that the default is 30 and the ceiling is 1000, and how to check the response's own perPage field. files points at tools/search/provider.go for the constants and the Parse function, and at apis/record_crud.go for the handler that passes the query through. confidence is the agent's own rating, with the question that would raise it when it is low, such as the exact URL the customer called.
Your webhook receives the object as data.result in the run.completed payload, which carries results up to 16 KiB, well over what this reply needs. Your backend parses and validates it, attaches it to the ticket as a draft, and leaves the send to a person. Before sending, the support person opens the cited lines and checks them against the customer's report: the URL they used, whether their project registers its own list hooks, and the collection's list rule.
The session keeps the whole investigation in its transcript at GET /o/{org}/sessions/{id}/messages: each file the agent opened, each search it ran, in order. When an engineer is asked to confirm the reply, they read that record instead of repeating the search.
Run it on every new support ticket
Each ticket your help desk creates calls POST /o/{org}/sessions once, with the question in input and the repository in resources. Send the ticket id as the Idempotency-Key header so a help desk that delivers its webhook twice still starts one run, and store the returned execution_id on the ticket.
With a webhook set on the API key, your backend hears back when each turn finishes, with the reply in data.result. When the customer writes back with the URL they called, send it as a follow-up to POST /o/{org}/sessions/{id}/messages: the parked sandbox wakes with the clone and its earlier reading still there.
The use case this job follows, with its automation and trigger: Run an agent per customer task.
Why run it on Rush?
Answering a PocketBase behaviour question from code means a checkout, a Go-aware search through apis/ and tools/, and someone who knows where the defaults live. A Rush run has the repository cloned in its own sandbox when it starts, reads as far as the question needs, and gives your backend a typed answer. No support engineer has to stop and pull the repository.
Tickets arrive in bursts, and each one gets its own run, up to the key's limit of runs in progress, instead of a queue behind one engineer. Every reply carries file and line citations plus the session's full record, so a support person can send a code-based answer with confidence and engineering sees only the tickets that are real bugs.
Frequently asked questions
Will the agent change my PocketBase code?
The prompt says not to, and the request asks for an answer, not a pull request. The transcript records every command the agent ran, so you can confirm it only read files.
What if my project extends PocketBase with its own hooks?
Point resources at your own application repository rather than the framework. The agent reads your main.go and any pb_hooks scripts, can run go mod download to read the PocketBase version your go.mod pins, and the reply says when one of your hooks, such as a records list handler, is the cause.
How do I get the reply as structured data?
Ask for JSON in the prompt, as this request does, and parse data.result from the webhook or result from GET /o/{org}/sessions/{id}. Validate the parsed object against your own schema before it reaches a person or a customer.
Can the agent see my customers' records?
Only what you send. This request has the repository and the question, and nothing from your PocketBase database. If a ticket needs the customer's collection rules or a sample URL, include them in input.