What the agent does
The agent turns the ticket's acceptance criteria into a bounded Go change. In a service like miniflux/v2, go.mod:1 names module miniflux.app/v2 and line 6 declares go 1.26.0. The agent reads those requirements before running checks, then maps the issue to fetching, parsing, storage or the HTTP API. A complaint that feed refresh returns the wrong error needs a different reproduction from a request to change outgoing feed headers. The Linear snapshot must make that distinction explicit.
For a fetcher ticket, the agent follows internal/reader/handler/handler.go:123–133, where NewRequestBuilder is configured with credentials, user agent, timeout, proxies and TLS behavior. It checks which option the acceptance criteria actually concern instead of adding a second HTTP client. internal/reader/fetcher/request_builder_test.go:31–45 uses httptest.NewServer to inspect a real Custom-Header request. That provides a concrete pattern for a regression that observes what the fetcher sends without contacting a production feed or depending on an external publisher.
For reader-facing behavior, it follows internal/api/feed_handlers.go as well as the shared handler. Lines 71–79 read request.UserID(r), check FeedExists(userID, feedID) and return not found when that user's feed does not exist. The agent preserves that ownership boundary while testing the ticket. A fetcher-only test cannot prove the API response contract, so a change that affects HTTP status or persistence needs the corresponding application-level evidence with isolated database state.
The agent runs the focused package checks and go test ./..., then uses the stronger test command when appropriate: Makefile:101–102 defines go test -cover -race -count=1 ./.... It distinguishes this from the separate integration-test target, which initializes a database and starts the service. The PR links the supplied Linear issue, explains the regression and includes command outcomes. Your caller reads the issue and comments through its authorized Linear connection and later posts the returned PR URL; the harness-only request itself grants no Linear account tools.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Implement the Go service ticket whose Linear URL, description, comments and acceptance criteria the caller appends below. Require that context before editing. Trace the existing feed fetcher, reader handler and affected HTTP endpoint. Extend the current implementation rather than adding a second request path. Add Go regression tests that exercise real behavior, using httptest for controlled HTTP responses and a disposable database when persistence is involved. Preserve user ownership, network restrictions and TLS checks unless the issue explicitly authorizes a reviewed change. Run focused package tests, go test ./..., and the repository's race-enabled test command when supported; report exact output and limitations. Open a pull request linking the issue and return its URL for the caller to comment on Linear. Do not merge or contact production feeds.",
"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
The result is a pull request with a focused fetcher or handler change and a regression that fails for the ticket's original condition. Its description follows the path from incoming request or scheduled fetch to the affected behavior. If the change alters an outgoing header, the evidence shows what the local test server receives. If it alters the reader API, the evidence includes the HTTP result under the relevant user identity rather than only a helper return value.
The reviewer compares the Linear acceptance criteria with the changed files, examines the command record and checks whether database integration was exercised. The standard suite and the separate integration target are labeled honestly. A race-enabled test failure, unavailable Go toolchain or missing database remains visible in the PR. The session answer supplies the link for your issue integration; no upstream Miniflux issue, branch or comment is created by this example.
Run it on every Linear feed ticket labeled agent
Your Linear webhook handler selects scoped feed-service issues and resolves their repository mapping. It fetches the issue and comments with its own authorized connection, appends that snapshot to input and submits a session. The current quickstart notes that built-in Linear sign-ins cannot yet be named on sessions, so this caller-side handoff is explicit. It does not rely on an instruction in the prompt to manufacture access.
Deduplicate deliveries for the same ticket and revision, then collect the result through a session read or the key's completion webhook. Your handler comments the returned PR URL on the issue only when a PR is actually present. Leave acceptance, issue closure and merging with the maintainer, especially when the change affects feed networking or ownership.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Feed-reader work often needs controlled HTTP responses, a particular Go toolchain and database setup. Rush gives the task its own sandbox, keeping fixture servers and test state separate from an engineer's local service. The agent can trace the existing fetcher without relying on whatever feeds happen to be available from a laptop at that moment.
Independent feed tickets can run separately within the configured concurrency limit. Each run keeps its own test command and output in the transcript, so a reviewer can inspect whether the reproduction used a local server, a database-backed endpoint or only a package test. The returned PR carries an argument about behavior with inspectable evidence, while the caller keeps ownership of the Linear workflow.
Frequently asked questions
Is go test ./... the same as the integration target?
No. The Makefile has a separate integration-test target that prepares a database and starts the application. The agent reports the standard suite and integration coverage separately so a package-level pass is not mistaken for an end-to-end API check.
Can it reproduce a feed timeout without contacting the publisher?
A controlled httptest server can reproduce many HTTP response and timeout conditions. The existing fetcher tests already use local servers for request assertions. Network conditions specific to a production publisher remain an explicit verification limit.
Will it relax TLS validation to make a feed work?
The prompt requires existing security checks to remain in place unless the issue explicitly authorizes a reviewed change. A connection error needs diagnosis before a policy change. The PR should explain the condition and test the intended boundary.
Who writes the pull request link back to Linear?
Your issue integration does, using its own authorized connection after reading the session result. The displayed session request contains only a harness, input and repository resource. It does not silently give the sandbox permission to comment.