What the agent does
The agent begins with the source of job timing, because a queue is not a history of completed executions. CodeTriage's Gemfile pins Rails 8.1.3.1 and includes Sidekiq and Postgres. config/routes.rb mounts Sidekiq::Web inside an authenticated u.admin? constraint. The repository therefore already has a queue-administration entry point and an administrator role to follow. The request asks for a page listing the slowest background jobs from the last day, not a second queue dashboard or a replacement authentication system.
It reads app/jobs/application_job.rb, representative jobs and db/schema.rb to find the available evidence. ApplicationJob only selects the default queue, and the schema has no completed-job duration table. PopulateIssuesJob illustrates real repository work, but does not persist an execution-time record. The agent states this limitation before promising yesterday's slowest jobs. It asks the team to approve an existing timing source or narrowly scoped recording, including retention, how retries appear and whether failed attempts belong in the list.
Once that decision is approved in a follow-up, it implements the read-only page with the existing layout and server-side admin checks. The list sorts by actual execution duration inside an agreed time window and labels that window clearly; queue wait time must not be substituted for runtime. Job arguments need an explicit display policy, because an argument may contain a credential or personal information rather than a harmless identifier. The agent uses synthetic executions for screenshots and verifies empty history, boundary timestamps, ordering and redaction. It does not claim to recover past executions that were never recorded.
Verification follows the existing CI workflow: Standard Ruby checks, a Postgres-backed test database, bin/rake test and the seed check. New tests request the page as an administrator, an ordinary signed-in user and an anonymous visitor, including direct URL access. If approved timing instrumentation is necessary, the tests also check its records and retention behavior without contacting external services. The team reviews the screenshot and data-source explanation before the agent opens its pull request, using a later session turn for corrections rather than simultaneous conflicting instructions.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Build an administrator-only, read-only page listing the slowest background-job executions from the last day with safely displayed arguments. Inspect the Rails layout/auth, Sidekiq integration, job classes and schema first. Distinguish runtime from queue wait time. If completed execution timing is unavailable, propose the smallest existing-source integration or recording change, including retention, retry semantics and argument redaction, and end the turn awaiting a follow-up approval. Do not fabricate past history. After approval, implement the page with server-side admin authorization and tests for anonymous/non-admin refusal, time boundaries, duration ordering, empty history and redaction. Use synthetic jobs for screenshots; do not run real email or GitHub jobs. Run relevant tests, bin/rake test and repository lint checks where supported. Ask before adding dependencies and open a PR with evidence and remaining 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 pull request contains the admin view, its query or approved timing-source integration and the tests that establish who can read it. If new recording is approved, the description explains when collection begins and what information is retained. It does not present Sidekiq's current queue contents as a complete list of yesterday's executions.
The reviewer checks the duration definition, timestamp window, argument redaction and access control before merging. Browser screenshots demonstrate the page with synthetic data; test output covers cases such as a non-admin requesting the route directly. The session answer names checks that could not run and links the evidence that exists, rather than inventing a performance history or successful deployment.
Run it on every job-visibility feature request
Have an internal ticket webhook send the repository URL and the agreed visibility requirement to the sessions API. Keep the returned execution identifier on the ticket so the team can read the proposal and commands. When the data-source proposal turn finishes, send an approval or narrower requirement to the same session. Use the key's completion webhook to notify your review system after each turn, without starting a duplicate implementation for every comment.
The use case this job follows, with its automation and trigger: Steer a run as a team.
Why run it on Rush?
A slow-jobs admin page touches operational data and authorization together. A Rush sandbox gives the agent a separate Rails checkout and database where synthetic durations can be checked without sending real mail, fetching real issues or displaying production job arguments. The transcript keeps the distinction between evidence found in the repository and information that still needs an approved source.
The team can review a concrete proposal, then continue the retained sandbox with a follow-up after the turn ends. That avoids turning a missing duration source into an unnoticed monitoring project. Other approved admin tasks can run independently within the concurrency limit, with separate diffs and tests instead of a shared laptop branch containing several unfinished features.
Frequently asked questions
Can it show yesterday's slowest jobs immediately?
Only if the application already retains suitable execution timings. The example schema does not provide that history, so the request requires a data-source decision before implementation.
Will the page expose every serialized job argument?
The task requires a reviewed display policy and redaction tests. Synthetic screenshot data does not justify exposing production secrets or personal information.
Does this replace Sidekiq Web?
No, the existing queue dashboard remains in place. The new page answers a narrower historical-runtime question and follows the application's administrator rule.
Will verification execute real background jobs?
The prompt forbids running real email and GitHub jobs for this page. Tests and screenshots use controlled data, with any necessary source integration documented separately.