# The Build Factory: see what your coding agents actually shipped > Run coding agents like a factory you can see into: a proof page on every pull request, a changelog every day, both read on a phone. By Azim Ahmed, Founder · Published October 19, 2026 · Updated October 31, 2026 · [Playbooks](https://pr-1769-stg.superartifacts.app/blog/category/playbooks.md) · ~6 min · Part 1 of [The Build Factory](https://pr-1769-stg.superartifacts.app/blog/series/build-factory.md) Topics: Proof of work, Changelogs, Templates, Reviewing on a phone ## In short - Every pull request an agent opens ships one private page of pictures that shows what changed, built from the pr-proof template. - Every day ships a changelog page in plain words for the people who use the product, built from the changelog template. - Both pages keep one address and gain a version each time they are republished, so the link you already have always shows the newest. - You review from a phone, in minutes, instead of reading diffs and terminal logs on a laptop. A build factory is a way of running coding agents where every unit of work comes out with evidence you can read in a minute: a page of pictures for each pull request, and a page of plain-words changes for each day. You stop asking an agent what it did. You open a link. This is the first part of a series about running agents that way. It covers the two pages that make the work visible, how they compare, and the prompt that sets them up. ## What is a build factory? It is an agent setup with two outputs besides the code. Each pull request publishes a **proof page**: screenshots, a short recording or a diagram of the change, with one line of caption each. Each day publishes a **changelog page**: what shipped, written for the people who use the product. Both are artifacts on Super Artifacts, built from marketplace templates. The agent fills the template's document and publishes it over MCP; the platform renders it and hands back a private link. Nothing about the factory needs a new tool on your machine. The agent you already use does the work. ## Why can't you see what your agents are doing? Because the default evidence an agent produces is written for another program. A pull request description says "updated the retry logic and added tests". A terminal log says 214 passed. Neither tells you what a person will now see on the screen, and neither fits on a phone. So review turns into one of two things. You either trust the summary, or you check out the branch and run it yourself. The first lets mistakes through. The second makes you the bottleneck for every change, which defeats the reason you handed the work to an agent. I review every pull request in this repository from my phone. That only works because every pull request arrives with a page made for exactly that screen. ## What goes on a proof page? Pictures first. The pr-proof template is a phone-first review page for one pull request, in two layers: - **The pictures** are the proof: before and after screenshots, a short recording of a flow, a diagram for a change that has no screen. Each carries one caption, and a tap opens it full screen. - **Under the hood**, folded beneath the pictures, is the technical layer: a plain-words story of what changed and why, review notes marked breaking, risky or safe, the file map, and the few hunks of the real diff that carry the change, each annotated. ![A pull request proof page on a phone: a verdict, the pictures of the change and its checks, one reviewer page.](https://pr-1769-stg.superartifacts.app/screenshots/docs/recipes-pr-proof-light.b9c7ee60.webp) *The pr-proof template's sample: one change, its evidence and its risk on one phone screen.* The slug is `pr-proof-` followed by the pull request's number. Publishing again lands as a new version of the same artifact, so the link in the pull request keeps showing the newest set. A project rule that matches every slug starting with `pr-proof-` gathers them in one place, and the project's own audience decides who else can open them. > **Tip** > > A change with no screen, such as a migration or a background job, still gets a picture: a diagram of before and after. It never needs to be a pasted test run. ## How does the daily changelog work? The changelog template turns merged work into a release page somebody outside the team can read. Releases run newest first, each with a version, a date, a headline and entries grouped as added, changed, deprecated, removed, fixed or security. A release that makes the reader change something carries a callout with the upgrade steps. ![A changelog page on a phone, releases listed newest first with their entries grouped by kind of change.](https://pr-1769-stg.superartifacts.app/screenshots/docs/recipes-changelog-light.9bb1b1b2.webp) *The changelog template's sample: what changed, and why it matters to the person reading.* In the setup below, an agent drafts the day's entries from the pull requests that merged, rewrites each one for the reader, and publishes a page for review. A person reads it, picks what goes out, and approves. Each new day is prepended to the same document and published as a new version of the same artifact, so there is one address for the whole history. ## How do the proof page and the changelog compare? They answer different people's questions, at different moments, from the same work. | | Proof page | Daily changelog | | --- | --- | --- | | Template | `pr-proof` | `changelog` | | Made | Once per pull request, republished as it changes | Once per day, prepended to one history | | Reader | Whoever approves the change | The people who use the product | | Question it answers | Is this change right? | What is different since I last looked? | | Content | Pictures first, the diff folded underneath | Short entries in plain words, grouped by kind | | Who can open it | Private: you and whoever you share it with | Private until you choose to share it | For a change that is best told as a narrated walkthrough, the pr-video-overview template is a player for one: a strip of key changes, each its own short recording with chapters, and a comment box that stamps every note with the moment on screen. For evidence that mixes video with screenshots and diagrams, pr-proof is the better fit. ## How do you set it up? 1. **Connect your agent** Add the Super Artifacts MCP server to the agent you already use and approve its sign-in once. The connection stays until you revoke it. 2. **Give it the two standing instructions** Paste the prompt below into the instructions your agent reads at the start of every session, such as a project instruction file. 3. **Open one pull request and read the link** The agent publishes the proof page, sets it private and puts the link in the pull request. Open it on your phone and check the pictures match the change. 4. **Approve the first changelog** At the end of the day the agent publishes the changelog page for review. Read it, cut anything nobody outside the team would notice, and publish. **Run my agents as a build factory** ```prompt From now on, every pull request you open ships proof of work. Use the Super Artifacts MCP server and the pr-proof template: show the change in pictures (screenshots, a short recording, or a diagram when there is no screen), one short caption each, and put the code-level detail in the recap layer underneath. Publish to the slug pr-proof-, set it private after every publish, and put the link in the pull request. Republish to the same slug when the change moves on. At the end of each working day, use the changelog template to write what merged that day for the people who use the product: one or two plain sentences per change, grouped by kind, internal-only work left out. Prepend it to the same changelog document, show it to me, and publish only when I approve. ``` ## What does this not do? It does not judge the change for you. A proof page makes the evidence quick to read; deciding whether the evidence is right is still the reviewer's job, and a page of confident pictures about the wrong thing is worse than none. Keep the agent's proof about the change in front of you, not a tour of the whole product. It also does not replace your tests. The pictures show what a person sees; the tests still decide whether the code holds. ## Questions ### Do I need to read the code to approve a pull request this way? You can, and the proof page carries the hunks that matter, annotated, folded under the pictures. Most of the time the pictures and the plain-words story are enough to decide whether to look closer. ### Who can open a proof page? Only you and the people you share it with. Artifacts are private by default, and a proof is set private again after every publish, because it holds real source and real screens. ### What happens when the agent fixes something and publishes again? The same address gets a new version. The link already in the pull request shows the newest one, and the earlier versions stay in the artifact's history. ### Does the changelog send itself? Not in this setup. An agent drafts the entries from merged pull requests and publishes a page for review; a person approves before anything goes out. ## Try these templates - [pr-proof](https://pr-1769-stg.superartifacts.app/marketplace/pr-proof.md) - [changelog](https://pr-1769-stg.superartifacts.app/marketplace/changelog.md) - [pr-video-overview](https://pr-1769-stg.superartifacts.app/marketplace/pr-video-overview.md) ## Keep reading - [How do you connect Hermes Agent to Super Artifacts?](https://pr-1769-stg.superartifacts.app/blog/connect-hermes-agent-to-super-artifacts.md): Three terminal lines connect Hermes Agent to Super Artifacts with a short code, so your agent can publish private pages and read back what visitors submit. (October 20, 2026)