# Engineering: a sprint review, written

> A scenario: an engineering lead asks the agent that did the work for a sprint review with a retro form, then asks it what the team raised most often.

*A scenario, not a customer story. No company, person or figure here is real; every step is something the product does today.*

## An engineering lead, end of the sprint

The work is in commits, pull requests and a chat thread. The review is a meeting where somebody shares their screen. Here, the agent that did the work writes it up.

## Where they are

Two weeks of work is spread across a repository, a tracker and a dozen threads. Somebody spends Friday afternoon turning it into a review, and the retro is a board of notes nobody opens again.

Meanwhile the agent that wrote half the code already knows what changed, and why.

## What they ask for

- A sprint review from this sprint's work
- What did the team raise?

Each request is a Copy prompt button on the page.

## What the agent builds

A review written from the repository, with a retro form underneath that the team answers.

- Review: Shipped, Slipped, and why, Next
- Retro: What went well?, What did not?

## What happens next

1. **Ask from the agent that did the work.** Claude Code, Codex, Cursor, Gemini CLI and twenty other agents connect over MCP with one address, and one without MCP can read the skill file instead. The agent that wrote the code is the one that writes the review.
2. **The team answers on the page.** Everyone you shared it with signs in and fills in the retro form. Each answer lands as a row your agent can read back — it is data, not a screenshot of a board.
3. **Talk to your agent about the answers.** Your agent reads them with the same tools it publishes with, so "what did people keep raising" is a question you ask it rather than a spreadsheet you build.
4. **Next sprint, a new version.** Ask again in two weeks. Publishing to the same address makes a new version and keeps every earlier one, so the sprint history is the page history.

## What it replaces

- A screen-share of the tracker in the review meeting
- A retro board of notes nobody reads afterwards
- Writing the summary yourself on a Friday afternoon

## What it does not do

- Super Artifacts cannot see your repository. Your agent can, and it writes what it found.
- Two people do not edit the page at once. The agent writes it; the team answers it.
- It runs nothing on a schedule. A new sprint means a new request.

## The same move, elsewhere

Proof of work for a single change is the same idea, smaller: every pull request in this product's own repository ships a page like this, published the same way.

## The other case studies

- [Founders](https://superartifacts.app/case-studies/founders.md): A projection you can edit, and an update for investors that is a link rather than a deck.
- [Product](https://superartifacts.app/case-studies/product.md): A feedback survey for users, and the answers read back in one place.
- [People](https://superartifacts.app/case-studies/people.md): A hiring board for one role, and an onboarding checklist for the person you hired.
- [Revenue](https://superartifacts.app/case-studies/revenue.md): An onboarding page for one customer, shared with the people on their side.