What the agent does
The agent maps the user-write and authorization paths before adding a table. In brocoders/nestjs-boilerplate, src/users/users.controller.ts protects its versioned users controller with AuthGuard('jwt'), RolesGuard and @Roles(RoleEnum.admin). Its create, update and remove methods call UsersService, but their signatures do not currently pass an actor. The audit change must obtain the actor from the authenticated request and carry it to the write, rather than trusting an actor identifier submitted in a DTO.
The persistence path already supports deletion semantics. src/users/infrastructure/persistence/relational/repositories/user.repository.ts calls softDelete(id) for removal, and src/database/migrations/1715028537217-CreateUser.ts defines deletedAt on the user table. The agent extends these writes with audit entries for actor, target, action and time. It defines which user-changing entry points the issue covers, follows other callers of UsersService, and handles the user mutation and audit insert atomically so a failed transaction cannot leave a misleading history.
The repository supports relational and document adapters. Its .claude/skills/generate/SKILL.md directs resource creation through the generators and selects the all-database variant when its script is present in package.json. The agent follows that contract, makes the Postgres audit_logs migration explicit and explains the document-adapter scope. It protects GET /api/v1/audit-logs using the existing authentication and role checks, reuses pagination conventions, and keeps passwords, tokens and entire request payloads out of audit records.
test/admin/users.e2e-spec.ts already signs in and exercises the real users API with Supertest. The agent extends that flow to verify persisted audit entries and admin reads, then tests ordinary-user and unauthenticated refusals with no unauthorized writes. docker-compose.relational.test.yaml supplies Postgres 17.9-alpine and the test API. It runs npm run lint, npm test -- --runInBand and the relational e2e suite in non-watch mode against the sandbox database, recording setup failures separately from assertion failures.
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 requests user-change auditing: record who created, updated or deleted a user, the target, action and timestamp in audit_logs, and expose GET /api/v1/audit-logs to admins only. Read the existing user controller, service, repository adapters, role checks and generator instructions first. Preserve soft deletion. Obtain actors from authenticated context, never caller-supplied DTO fields; define coverage for other user-write entry points and keep each mutation and audit entry atomic. Follow the repository's resource generators and state the relational/document scope. Exclude passwords, tokens and full request bodies. Add database-backed tests for create/update/delete records, rollback behavior, admin reads and denied ordinary/anonymous requests without side effects. Run npm run lint, npm test -- --runInBand and the Postgres e2e suite in non-watch mode in the sandbox. Open a pull request linking the supplied Linear issue and list actual checks and limits.",
"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 deliverable is a PR with the generated audit resource and reviewed database migration, actor propagation through the existing user-write path, the protected read endpoint and integration tests. It explains what remains in the history after a soft delete and which entry points generate records. Pagination and authorization follow existing conventions. The description identifies the adapter coverage instead of implying that a Postgres-only test proves equivalent MongoDB behavior.
A reviewer checks that clients cannot choose the recorded actor, that rejected requests leave no mutation or audit side effect, and that transaction failures cannot separate the record from the change. The reviewer also checks the migration, deletion references and response serialization for sensitive fields. The result includes real test commands and output; a controller test that replaces the repository cannot establish that the history survives an actual database write.
Run it on every Linear issue labelled audit-log
Have your Linear webhook receiver select approved audit issues and send their acceptance criteria and URL as input to the sessions API. Put the GitHub App-accessible repository in resources; keep real credentials and user records out of the prompt. Use an idempotency header for a repeated delivery of the same issue revision. Your automation can read the session result or receive the key's completion webhook before asking a person to review the migration and authorization changes.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Audit work needs a database, authenticated requests and proof of rejected operations. Rush runs the agent in its own sandbox so it can exercise disposable test data instead of a laptop's development database. The isolated working copy also keeps an unfinished migration away from your current feature branch. The requested evidence follows a user write all the way into persisted audit history.
Separate APIs can receive independent audit tasks, each with its own session and result. The transcript keeps the commands and outputs needed to inspect database setup, migration execution and access tests. That lets a reviewer distinguish a tested permission boundary from an annotation that merely looks correct, and send a follow-up after the turn finishes when the intended audit scope needs refinement.
Frequently asked questions
Does this introduce soft deletion?
The inspected relational user repository already calls softDelete(id). This task records the deletion event while preserving that behavior. Replacing it with a hard delete would change the issue's scope and the meaning of existing user references.
Can clients provide the actor identifier?
The request explicitly forbids that. The implementation must derive the actor from authenticated context and test that a caller cannot impersonate another actor through the payload. Background or self-service writes need a stated attribution policy if they are in scope.
Will audit records contain before-and-after user objects?
The requested history needs an actor, target, action and timestamp. Copying complete objects can leak credentials or personal data and is outside this example's scope. If an issue requires changed-field details, it should name an explicit safe field set and its retention policy.
How is admin-only access verified?
The agent reuses the existing JWT and role checks and requests real allowed and denied API tests. Tests must cover an administrator, an ordinary user and an anonymous request. The PR reports those results separately from database persistence and rollback checks.