What the agent does
The agent starts from the Linear issue text and the repository in its own cloud sandbox, and maps where post dates already appear before it invents a new component. In a site like satnaing/astro-paper (AstroPaper v6.1.0, Astro ^7.0.3, Node >=22.12.0, pnpm lockfile 9.0), posts live under src/content/posts as a content collection defined in src/content.config.ts: the schema requires pubDatetime, optional modDatetime, title, description and tags, loaded with Astro's glob loader from **/[^_]*.{md,mdx}. There is no reading-time field and no test directory in the tree.
It then finds every place a reader sees the date. src/components/Datetime.astro formats pubDatetime (or modDatetime when newer) with dayjs and the post timezone, showing a calendar icon and D MMM, YYYY. src/components/Card.astro renders that component under each post title in lists. src/pages/posts/[...slug]/index.astro passes pubDatetime and modDatetime into PostLayout.astro and renders <Datetime … size="lg" /> on the post page. The agent plans a build-time estimate from the collection entry body (words or characters divided by a fixed words-per-minute), exposed as a small helper under src/utils/ and rendered next to the existing date in both Datetime.astro and the list card path, without changing the frontmatter schema unless the team wants a stored field.
It implements the helper, wires it into Datetime.astro (and any list that bypasses that component), and adds tests for the word-count and minute-rounding edge cases. AstroPaper's package.json has no test script today (dev, build, preview, lint, format), so the agent adds a focused unit test runner only for the new helper rather than inventing an end-to-end suite. It then runs pnpm build, which is astro check && astro build && pagefind --site dist && cp -r dist/pagefind public/, and the new tests, fixing type or check failures before it pushes.
Last, it opens a pull request whose description links the Linear issue, lists the files it touched (Datetime.astro, the utils helper, Card or post page if needed, and the new tests) and shows the build and test commands with their exit status from the sandbox transcript.
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 Reading Time to Posts in an Astro Site. Show an estimated reading time next to each post's date on the post page and in post lists, computed at build time from the content collection.\" Do the work in this repository, add tests for it, run pnpm build and the new tests, 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 on its own branch. The description starts from what the agent found: dates already flow through Datetime.astro via Card.astro and the post slug page, the posts collection has no reading-time field, and pnpm build is the project check. The diff adds the build-time estimate next to those dates and tests for the helper, and it links the Linear issue so the issue shows the work.
The session transcript keeps every command with its output: pnpm install if needed, the new test run, and each pnpm build attempt, including any astro check failures before the fix. If the repository has GitHub Actions, those checks run on the pull request too.
Before merging, a reviewer checks that list and post pages both show the estimate, that drafts and empty bodies do not break the build, that the words-per-minute constant is documented in the PR, and that pnpm build still produces the Pagefind index under dist.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Computing reading time at build time means running the real Astro check and Pagefind step on a machine that has Node 22 and pnpm, not a half-matched laptop toolchain. In a Rush sandbox the agent installs from pnpm-lock.yaml, runs pnpm build end to end and keeps the log, so a broken content collection or a type error in Datetime.astro shows up before anyone reviews the PR.
A label in Linear becomes a reviewable change with evidence attached: the transcript shows the agent reading content.config.ts and the date components before editing them, and several labelled Astro issues can run at once, each in its own sandbox with its own branch, up to the key's max_concurrent limit.
Frequently asked questions
Does it add a readingTime field to every post's frontmatter?
Only if that is the cleanest fit. In an AstroPaper-shaped site the body is already in the content collection at build time, so the usual change is a util that estimates from the entry body and a display next to Datetime.astro, without forcing authors to set a frontmatter field on every MDX file.
Will it work with pnpm and Astro 7?
Yes when the lockfile and engines match what the agent finds. For AstroPaper that is pnpm lockfile 9 and Node >=22.12.0, and the agent runs the existing pnpm build script rather than inventing npm commands.
There are no tests in the repo today. What does it add?
Focused tests for the new reading-time helper and its rounding rules. It does not invent a full browser suite; it keeps the change small and still runs pnpm build as the project-wide check.
Does reading time show in the archives and tag lists too?
Wherever Card.astro or Datetime.astro already renders the date. If a page formats the date by hand, the agent either routes it through the shared component or updates that call site and says so in the pull request.