PR walkthroughs your agent keeps at a URL

The workflow

1. Start after the branch is coherent enough to review. Give the agent the pull request description, diff, test results and any product acceptance notes. Exclude credentials, customer records and logs that do not belong in a review artifact.
2. Use a direct prompt: Build a PR walkthrough for the current branch. Create one page for a reviewer who has not seen the agent session. Include the user problem, before and after behavior, changed-file map, architecture notes, exact test checklist, known limits and unresolved questions. Link claims to repository paths. Do not invent test results.
3. Ask the agent to create a static page in the initialized folder. The required piece is the page itself. This walkthrough does not need Postgres, login, a scheduled job or a custom domain unless the review material genuinely has an interactive or restricted requirement.
4. Review the draft against the branch. Confirm that every file named exists, every test status matches command output, and every limitation is visible. A walkthrough is useful only when it reduces reviewer uncertainty rather than hiding it behind polished prose.
5. Push the files, create a named checkpoint and choose a share boundary. A public link fits open work. A password or invited-person share fits a private review. Put the returned URL near the top of the pull request description.
6. When a reviewer comments on the artifact, let the agent read the feedback and revise the walkthrough or the implementation. Publish another checkpoint at the same workspace so later readers see a coherent, updated explanation instead of a trail of stale screenshots.

Setup

grain login
cd path/to/repository
grain init
# Give the agent the walkthrough prompt and review its files.
grain push
grain checkpoint -m "PR walkthrough ready"
grain share --password <pw>
# Or use --public for an open repository.

Download the Mac app before running the sequence. Initialize the repository folder, not a parent directory. The artifact uses a page and a share URL. Postgres is unnecessary for a read-only explanation, login is unnecessary when password or public sharing covers the audience, and no scheduled job is involved. A custom domain is optional on Pro, but the default https://<slug>.share.rungrain.com address is enough for a pull request. Pick the access mode before copying the URL into the review. Then open it outside your signed-in session and confirm that the reviewer can reach exactly what you intended.

What you get

• A stable review page that begins with the user-facing change rather than an agent transcript or an unannotated diff.
• A changed-file map that tells reviewers where to spend attention and why each file changed, while the repository remains the source of truth.
• A test checklist that separates commands already run from manual checks still required. The agent should never convert an unrun check into a passing claim.
• A place for architecture notes, migration concerns and known gaps that would otherwise be scattered across chat messages and review replies.
• A share boundary suited to the repository: public, password-protected or limited to invited people.
• Comments attached to the artifact, available for the agent to read and act on during the next revision.
• Files you can fetch with grain pull, so the explanation is not trapped in a screenshot or an expiring coding session.

Proof

Do not accept a marketing claim as proof that this improves review. Check the artifact yourself. Open the share in a clean browser, follow the changed-file map against the actual diff, run one listed test and verify that a comment can be left and returned to the agent. Close the laptop and revisit the address from another device after the coding session has ended. Grain's product promise is that published artifacts stay published, including on the free tier. The practical proof for this use case is whether the same walkthrough remains readable, accurately reflects the branch and shortens the time a reviewer spends reconstructing context.

Limits

• The walkthrough does not replace the pull request, source diff, required approvals or automated checks. It is a map for the review, not the record of merge authority.
• An agent can misunderstand a diff. Require file references and compare the page with the repository before sharing it.
• A static page cannot exercise an interactive change. Link to the relevant test environment or publish a separate app artifact when interaction is the thing under review.
• Do not publish secrets, private logs or customer data. Select password or invited-person sharing when the content should not be reachable by anyone holding a public link.
• The page can become stale after new commits. Update it and create another checkpoint when the implementation changes materially.
• Grain is not a code editor or general deployment platform. Keep editing, CI and production release work in the systems built for those jobs.

Frequently asked questions