# Turn Linear Issues Into Pull Requests for a NestJS API Turn a scoped Linear article-module issue into a NestJS pull request on Rush, with TypeORM-aware regression coverage and Jest results. [Run this on Rush](https://cloud.getrush.ai/run/linear-issue-to-pr/nestjs/), in a Project that has your repository. ## What the agent does The agent reads the ticket and identifies the NestJS module that owns the behavior. In lujakob/nestjs-realworld-example-app, src/article/article.module.ts:13 registers TypeOrmModule.forFeature([ArticleEntity, Comment, UserEntity, FollowsEntity]) and line 14 provides ArticleService. The ticket therefore needs more than a controller method name: it must state the article operation, caller identity and expected response. The agent reads the existing module, controller, service and affected DTO before deciding which layer should change. The article routes have explicit authentication wiring outside the controller. src/article/article.module.ts:22–31 applies AuthMiddleware to the feed, article writes, comment writes and favorite operations. src/article/article.controller.ts:24–26 delegates the public list to articleService.findAll(query), while lines 33–35 pass a user id into findFeed. A ticket about the personal feed should not be implemented by changing public listing semantics. The agent traces the exact entry point and preserves the existing authenticated route list. It inspects the database-dependent behavior and the actual test runner. src/article/article.service.ts:28–30 constructs a TypeORM article query and joins the author; lines 51–63 obtain articlesCount before applying the requested limit and offset. That ordering gives a reviewer something concrete to check for pagination work. package.json:11 defines "test": "jest --config=jest.json", and jest.json:11 discovers tests below src. A regression belongs where that configuration will find it, with the real query behavior exercised against an isolated database when the issue concerns persistence. The agent checks setup rather than assuming the existing suite is self-contained. ormconfig.json.example:2 selects "type": "mysql" and line 9 sets "synchronize": true. src/tag/tag.controller.spec.ts:13 opens TypeOrmModule.forRoot(), even though its line 34 later stubs findAll. This is not proof of article coverage. The agent adds the ticket's distinct regression, runs focused Jest checks and npm test, and keeps MySQL or legacy-tooling failures visible. The PR links the supplied Linear issue without bundling a NestJS or TypeORM upgrade. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "codex", "input": "Implement the scoped Linear issue appended below in this NestJS application's existing article module. The caller supplies the issue URL, description, comments, acceptance criteria and authorized scope; this body grants no Linear connection. Read module authentication wiring, controller, DTOs, TypeORM entities, service and Jest configuration. Reproduce the requested behavior with a discovered Jest regression using the real application path and disposable MySQL where needed; do not replace the affected query with a success stub. Preserve public-list versus authenticated-feed behavior. Make the narrow change, run focused tests and npm test, and report exact command outcomes and database or legacy-tooling blockers. Open a pull request linking the issue and return the URL for caller-side Linear commenting. Do not merge or upgrade the framework incidentally.", "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 1. **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. 2. **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. 3. **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 PR contains the article-module implementation and the regression needed by the ticket. Its explanation connects the acceptance criteria to controller input, service behavior and the serialized response. For pagination, a reviewer sees which behavior applies to total count versus the returned page. For comments or favorites, they see the relationship update and its verification. The file list stays centered on that operation rather than spreading into unrelated modules. The validation summary distinguishes a failing reproduction, the post-change focused check and the broader npm test command. Any MySQL preparation or old ts-jest compatibility problem is reported directly. Reviewers check whether the new test actually enters the affected query and whether the route keeps its authentication requirement. Your caller posts the PR link back to the Linear issue after reading the session result; the example describes that workflow without claiming a run or comment has happened. ## Run it on every Linear article issue labeled agent Route the approved Linear label through a webhook handler you control. The handler reads the issue and comments through its authorized Linear connection, resolves the NestJS repository and appends a bounded ticket snapshot to input. It then starts one session for that accepted ticket revision. The developer quickstart currently limits use of built-in Linear sign-ins on sessions, so the harness-only body shown here depends on supplied context rather than direct Linear tools. Suppress duplicate deliveries and avoid concurrent implementations of the same article operation. Collect the resulting PR URL from the session read or the API key's completion webhook, then comment the link through your integration. A label authorizes the scoped implementation request; it should not implicitly authorize framework upgrades, issue closure or merging. ## Why run it on Rush? A legacy NestJS project may need its own dependency tree and a disposable MySQL database before a short ticket can be tested. Rush isolates that setup in a cloud sandbox instead of changing a maintainer's global Node tools or local database. The agent can inspect module wiring and actual query construction while another task remains open on the engineer's laptop. Several independent tickets can be dispatched within the key's concurrency allowance. Their transcripts keep the exact Jest invocation and setup output alongside the patch, making it possible to distinguish an article regression from an environment failure. The useful result is a reviewable change tied to the ticket and its observed checks. A generic claim that the article module 'has tests' would not establish the requested behavior. ## Frequently asked questions ### Will the agent assume every article route is authenticated? It reads ArticleModule's middleware route list and the selected controller method. Public listing and the personal feed have different inputs. The regression must match the operation named in the ticket. ### Can the existing tag test stand in for article verification? No. That test concerns another controller and stubs its service response. An article issue needs evidence for the changed article behavior, including database interaction when that is the cause. ### Does TypeORM synchronization make database setup harmless? The example configuration enables synchronize, so the agent must use a disposable database. The task should never point that configuration at production or valuable developer data. A successful connection alone does not prove the schema matches the ticket. ### Can it still deliver if the old test tools fail? It can return the patch and the exact failure evidence, but must not claim the suite passes. A required tooling repair needs a clear explanation and scoped authorization. Unrelated upgrades should not be hidden inside an article feature.