What the agent does
The run starts from the repository URL in resources: the agent clones it into its own cloud sandbox and opens the TypeScript example the issue names. In aws-samples/aws-cdk-examples, that example is typescript/api-cors-lambda-crud-dynamodb/. Its package.json depends on aws-cdk-lib 2.262.1 and the aws-cdk CLI 2.1133.0, builds with tsc, and already lists Jest 30 with @swc/jest, though it has no test script yet. jest.config.js matches **/*.test.ts and loads aws-cdk-lib/testhelpers/jest-autoclean.
The stack in index.ts defines five NodejsFunction Lambdas on Node.js 24: get-one, get-all, create, update-one and delete-one, each bundling from lambdas/*.ts with the DynamoDB table name in the environment. None of them set deadLetterQueue or deadLetterQueueEnabled today, and there are no CloudWatch alarms in the file. API Gateway CORS helpers at the bottom of index.ts stay out of scope.
The agent gives each function its own SQS queue as a dead letter queue with a modest maxReceiveCount, using aws-cdk-lib/aws-sqs and the Lambda deadLetterQueue property on NodejsFunction. For every queue it adds a CloudWatch alarm on ApproximateNumberOfMessagesVisible so a depth above zero pages someone. The five Lambdas keep their existing DynamoDB grants and routes on /items.
Proving it means assertion tests the example never shipped. The agent adds a test script that runs Jest, writes a *.test.ts that synthesizes ApiLambdaCrudDynamoDBStack, and uses annotations / template matchers from aws-cdk-lib/assertions to require five SQS queues, five Lambdas with DeadLetterConfig, and five alarms. Then it runs npm test and npx cdk synth inside the example directory.
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 a Dead Letter Queue to a Lambda in AWS CDK. In typescript/api-cors-lambda-crud-dynamodb, give each Lambda an SQS dead letter queue and a CloudWatch alarm on its depth, with assertion tests.\" Do the work in this repository, add tests for it, run npm test and cdk synth in the example, 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. Its diff updates typescript/api-cors-lambda-crud-dynamodb/index.ts with the queues and alarms, adds a Jest test file beside it, and wires a test script in that example's package.json. The description quotes the issue and links back to it.
The checks on the pull request run npm test and cdk synth in the example. A reviewer reads the template assertions for one DLQ and one alarm per Lambda, confirms maxReceiveCount is set, and confirms the DynamoDB table and API routes are unchanged. Other language folders under typescript/ are left alone.
The session read keeps the record behind the pull request: npm install, the Jest run and the synth output. Anyone who questions a missing DeadLetterConfig can see the assertion that failed before the agent fixed it.
Run it on every Linear issue labelled agent
The Project's automation turns the label into the run. In the console, add an automation with a Linear trigger on linear.issue.labeled filtered to the agent label and this prompt; each labelled CDK reliability issue starts its own run in its own sandbox and opens its own pull request on the examples repository.
If the automation is not wanted, a small server can do the same: receive Linear's issue webhook, put the issue text into input, and POST to /o/{org}/sessions with the aws-cdk-examples repository in resources. A run.completed webhook on the API key posts the pull request when synth and tests pass.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
On a laptop this job needs Node for the example's toolchain, a CDK bootstrap-free synth, and enough patience to install aws-cdk-lib before Jest will load the assertion helpers. Each run on Rush boots its own sandbox with that already in reach, runs npm test and cdk synth itself, and keeps every command and its output.
DLQ work is easy to postpone until the first silent failure in production. Labelling the issue starts a sandbox that adds the queues, alarms and assertions without blocking whoever is mid-deploy on another stack in the same monorepo of examples.
Frequently asked questions
Does every Lambda share one DLQ?
No. The agent gives each of the five NodejsFunction constructs its own queue and its own depth alarm, so a failing create does not hide behind a delete backlog.
Is cdk bootstrap required in the sandbox?
No. The prompt asks for cdk synth and npm test, which only need the TypeScript app to compile and emit a template. No account credentials are required for that path.
The example had Jest but no test script. What gets added?
A test script that runs Jest with the existing jest.config.js, plus a new *.test.ts that synthesizes the stack. DevDependencies for Jest are already listed in package.json.
Will API Gateway routes change?
No. /items and /items/{id} keep the same methods and CORS OPTIONS mock. Only the Lambda functions gain dead letter configuration and alarms.