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 example the issue names. In serverless/examples, that service is aws-node-rest-api-with-dynamodb/. Its serverless.yml declares frameworkVersion 4, runtime nodejs24.x on arm64, and five HTTP API functions: create, list, get, update and delete against a pay-per-request DynamoDB table. package.json is type module and depends on @aws-sdk/client-dynamodb and @aws-sdk/lib-dynamodb at ^3.700.0, with no test script and no validator library yet.
Create and update already do a thin typeof check. todos/create.js parses event.body, requires text to be a string, and otherwise returns 400 with a single error string. todos/update.js requires text as a string and checked as a boolean, then runs an UpdateCommand. A malformed JSON body still throws from JSON.parse and surfaces as a 500 through the Lambda runtime, which is the failure mode the issue wants to replace.
The agent adds a JSON Schema for create (text required string) and update (text string, checked boolean, both required), validates with a small Ajv (or equivalent) helper shared by both handlers, and on failure returns 400 with a body that lists field-level errors instead of a bare string. Valid requests still write to DynamoDB exactly as before. List, get and delete stay unchanged.
Proving it means tests the example never had. The agent adds a test script, node test files that invoke create and update with missing fields, wrong types and invalid JSON, and asserts status 400 plus a field-errors array. Then it runs npm test and serverless package so the service still bundles under framework v4.
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 Validation to a Serverless API. In aws-node-rest-api-with-dynamodb, validate create and update bodies with a JSON schema and return 400 with the field errors instead of a 500.\" Do the work in this repository, add tests for it, run npm test and serverless package, 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 todos/create.js and todos/update.js, adds a shared schema helper, test files and the npm scripts needed to run them, and leaves serverless.yml routes intact. The description quotes the issue and links back to it.
The checks on the pull request run npm test and serverless package. A reviewer reads the 400 bodies for field errors, confirms invalid JSON no longer becomes an unhandled 500, and confirms successful create still returns 201 with the DynamoDB item. Other examples under aws-node-* are untouched.
The session read keeps the record behind the pull request: install, the test run and the package output. Anyone who questions a field-error shape can open the trajectory and see the exact fixture the agent sent.
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 API hardening 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 serverless examples repository in resources. A run.completed webhook on the API key posts the pull request when package and tests finish.
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 the Serverless Framework v4 CLI, Node 24 matching the runtime, and a clean install of the AWS SDK clients before handlers will load. Each run on Rush boots its own sandbox with that already in reach, runs npm test and serverless package itself, and keeps every command and its output.
Validation tickets are small and easy to leave at the bottom of a sprint. Labelling them starts one sandbox per issue so create/update schema work does not wait on whoever owns the DynamoDB table definition.
Frequently asked questions
Create already returns 400 for a bad text field. What changes?
The hand-rolled typeof checks become JSON Schema validation with a field-errors list, and invalid JSON is caught instead of throwing into a 500. The success path still uses PutCommand and UpdateCommand the same way.
Does validation run in API Gateway or in the Lambda?
In the Lambda handlers for this example. The service uses HTTP API events without a request schema block in serverless.yml; the agent keeps validation next to the handlers the issue names.
Will list and delete gain schemas too?
No. The issue names create and update bodies only. List, get and delete keep their current handlers.
Is a real DynamoDB table required for the tests?
No. The new tests call the handlers with fabricated events and stop at the validation branch before PutCommand or UpdateCommand runs, so no AWS account is needed in the sandbox.