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.
A scenario, not a customer story. No company, person or figure here is real; every step is something the product does today.
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
Copy it and paste it at the agent you already use. It asks for anything it needs to know.
- A sprint review from this sprint's work
- What did the team raise?
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 happens next
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.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.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.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.
Your first artifact is one conversation away
Connect the agent you already use, describe what you want, and it is live at a URL a reviewer opens on a phone.
No MCP support in your agent? Install the skill instead
The other case studies
- FoundersA projection you can edit, and an update for investors that is a link rather than a deck.
- ProductA feedback survey for users, and the answers read back in one place.
- PeopleA hiring board for one role, and an onboarding checklist for the person you hired.
- RevenueAn onboarding page for one customer, shared with the people on their side.