What the agent does
The agent implements the accepted behavior from a Linear issue, starting with its description, comments and explicit limits. An Express API like hagopj13/node-express-boilerplate has separate route owners: src/routes/v1/auth.route.js:9–16 registers login, registration, token refresh and email-verification operations, while src/routes/v1/user.route.js:11–18 applies auth('manageUsers') or auth('getUsers') to user management. A request to change profile validation must identify which entry point and which caller it concerns. The agent maps that boundary before writing a patch.
The caller obtains the issue and comments through its authorized Linear connection and appends a redacted snapshot to input. This distinction matters: the developer quickstart's 'Skills, connections and resources' section says a built-in Linear sign-in connects but cannot yet be named on a session. The displayed request grants no Linear tools. The agent can work from supplied context, while your integration posts the returned PR URL back to Linear. Do not imply that mentioning a ticket in prose silently grants read or comment permissions.
The agent reads the existing validation, controller and service behind the selected route, and inspects tests/integration/auth.test.js. Lines 32–47 send a registration request with Supertest, check that the response omits password, then inspect the stored user. That is useful evidence for an account change because a successful HTTP response alone can conceal an incorrect write. tests/utils/setupTestDB.js:6 connects Mongoose to the configured database, and line 10 clears its collections before each test, so the task must provision disposable MongoDB state.
It uses the repository's dependency conventions and commands rather than introducing another runner. The checkout contains yarn.lock; package.json:16 defines "test": "jest -i --colors --verbose --detectOpenHandles". The agent adds focused Jest coverage for the ticket's allowed and refused requests, runs npm test and records any open-handle or setup failure. The PR stays confined to the existing auth/user implementation, includes the Linear URL and explains how the tests establish the requested behavior.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Implement the scoped Linear issue whose URL, description, comments, acceptance criteria and allowed changes the caller appends below. Work in the existing Express auth and user routes, tracing validation, middleware, controllers, services and persistence before editing. The caller supplies Linear context; this body grants no Linear connection. Use the checked-in dependency lockfile. Add Jest regression coverage through the real application and disposable MongoDB for the requested behavior and relevant permission failures. Run focused coverage and npm test, keeping exact command results and setup errors. Open a pull request that links the supplied Linear issue and explains the change. Return its URL so the caller can comment it on Linear. Do not merge, deploy or use production data.",
"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 returned pull request links the Linear issue and changes only the auth or user behavior the ticket requests. Its description identifies the route, the validation rule and the affected persistence operation, with the regression that distinguishes the new behavior. The verification section states the focused command and npm test results separately. A test-environment failure remains a failure even when the patch appears plausible on inspection.
The reviewer checks that the route keeps its existing role requirements, that response serialization still excludes password data and that the stored record matches the acceptance criteria. Any token-related change needs tests for the relevant lifecycle, not a broad rewrite of authentication. Your integration then comments the returned PR link on the originating issue using its own authorization. The run's answer provides that link; this example does not claim that a comment or a PR already exists.
Run it on every Linear auth ticket labeled agent
Have your Linear webhook receiver select the approved label, team and repository mapping. It reads the latest issue and comments through your Linear connection, excludes private material the code task does not need and appends the resulting context to the session input. Start one POST /o/{org}/sessions call for each accepted ticket revision. Repeated label notifications should map to the same pending implementation in your caller rather than start competing account changes.
Collect the finished session's result by reading the session or handling the API key's completion webhook. After checking that the result actually includes a PR URL, your integration adds that URL as a Linear comment. Posting the link and changing the issue's workflow state are separate choices; this task asks for the link, not automatic closure or merging.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Account-route changes need controlled data and a clean dependency environment. Rush gives this work a separate cloud sandbox, so clearing MongoDB collections for tests does not interfere with an engineer's current API session. The ticket, checkout and command record stay together, which makes it easier to review a small user-management change without rebuilding the entire reproduction on a laptop.
Several scoped tickets can run independently within the API key's configured concurrency. Each result has its own PR and transcript, preserving which validation and permission checks actually ran. That evidence is useful when a test hangs on an open connection or a token test fails for an environmental reason. The maintainer reviews the proposed behavior with those limits visible instead of accepting a bare 'implemented' message.
Frequently asked questions
Does this use a built-in Linear sign-in inside the sandbox?
The example uses caller-supplied issue context. The current quickstart explicitly limits naming a built-in Linear sign-in on sessions. Your existing Linear integration reads the ticket and posts the returned PR link.
Can the ticket change which roles may manage users?
Only if the acceptance criteria explicitly authorize that permission change. Otherwise the agent must preserve manageUsers and getUsers requirements. Review the refused caller cases alongside the new allowed behavior.
Why use a disposable MongoDB database?
The integration helper clears configured collections before every test. Pointing it at useful data would be destructive. A task-specific test database lets the agent inspect real writes without risking development or production records.
Will a small ticket trigger a framework upgrade?
The request keeps the work within the existing Express implementation and dependency conventions. An unrelated runtime or package upgrade expands the review and can change authentication behavior. Report a genuine dependency blocker separately rather than silently bundling an upgrade.