What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and finds how the Gin app boots and logs today before adding middleware. In a codebase like gothinkster/golang-gin-realworld-example-app (Go 1.21, Gin v1.10.0, GORM with SQLite), hello.go builds the engine with gin.Default(), which already attaches Gin's Logger and Recovery, then mounts /api groups for users, articles and tags. Auth lives in users/middlewares.go as AuthMiddleware. Logging elsewhere is the standard library log package (log.Println, log.Fatal on startup). There is no X-Request-ID handling and no log/slog usage in the tree.
It designs one middleware that runs early on the engine (or on the /api group): read an incoming X-Request-ID or generate one, set it on the request context and on the response header, then log each finished request with log/slog as JSON including method, path, status and duration. It keeps gin.Default()'s Recovery unless replacing Logger intentionally, and documents that choice in the PR so operators are not surprised by duplicate access lines.
It adds table-driven tests beside the existing package tests (users/unit_test.go, articles/unit_test.go, common/unit_test.go): a request without an ID gets one on the response, a client-supplied ID is echoed, and the slog handler (or a test handler) records method, path, status and a positive duration. The project's tests use SQLite through common helpers, so the agent reuses that pattern rather than standing up Postgres.
Last, it runs go test ./..., fixes compile or assertion failures, and opens a pull request that links the Linear issue and lists the new middleware file, the hello.go (or router) wiring and the tests that prove the header and JSON fields.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Request IDs and Structured Logging to a Gin API. Add middleware that sets an X-Request-ID on every request and response and logs each request with log/slog as JSON with method, path, status and duration.\" Do the work in this repository, add tests for it, run go test ./..., and open a pull request that links back to the issue.",
"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 a pull request on its own branch. The description explains that the app used gin.Default() logging and stdlib log with no request ID, then shows the new middleware wired before the /api routes, the X-Request-ID behaviour and the slog JSON fields. The Linear issue is linked so the issue shows the work.
The transcript keeps go test ./... (and any go vet the agent ran) with full output. If GitHub Actions already run Go tests on the repository, those checks appear on the pull request as well.
Before merging, a reviewer checks that client-supplied IDs are validated or length-bounded, that sensitive paths or tokens are not logged, that Recovery still runs on panics, and that the new tests fail if the middleware is removed from the engine.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Request-ID middleware has to run against the real Gin engine and the package tests that already open an SQLite database through common. In a Rush sandbox the agent runs go test ./... on a clean module cache and keeps every failure line, so a broken middleware that drops the response writer or double-writes headers is caught before review.
Labelling an issue in Linear is enough to get a branch and a PR with proof: the transcript shows the agent reading hello.go and users/middlewares.go first, and several Gin issues can run in parallel, each in its own sandbox, up to the key's max_concurrent limit.
Frequently asked questions
Will it remove gin.Default()'s logger?
It prefers one access log. If Gin's logger and slog would duplicate lines, the agent switches to gin.New() plus Recovery and the new middleware, or keeps Default and documents why, and says which it chose in the pull request.
Does it accept a client-supplied X-Request-ID?
Yes when present and sane; otherwise it generates one. Tests cover both paths so a proxy that forwards correlation IDs keeps working.
Is the log format slog's JSON handler?
Yes for the request line the issue asks for: method, path, status and duration as JSON via log/slog. Startup messages may stay on the existing logger unless the agent migrates them in the same change and says so.
Do the existing RealWorld unit tests still pass?
They should. The agent runs go test ./..., which includes users, articles and common, after wiring the middleware so auth and article tests still hit the same routes.