# Add Reading Time to Posts in an Astro Site from a Linear Issue

Yes. An agent picks up the Linear issue, adds build-time reading time next to each Astro post date, runs the build and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-reading-time/astro/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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.

## 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.