Skip to main content
Proof is only useful when it’s easy to review and tied to the work it supports. A screenshot without an owner is just a file; the same screenshot linked to a PR and chat explains what it proves. The lifecycle is short — capture, review, attach — and every artifact carries an owner and a review state.

​
Where proof surfaces

Proof shows up in two places:
  • Chat — the proof drawer below the composer shows a thumbnail grid for the current session. Captions render in full under each thumbnail; click to preview at full size.
  • Lane and PR review — linked proof is surfaced alongside lane work and at PR closeout, where reviewers actually look.

​
Owners

A single proof can be linked to more than one owner. That link is what makes the artifact useful later, and adding an owner never drops the existing ones — provenance is preserved as evidence flows downstream.
  • Chat session — the conversation that produced it.
  • Lane — the worktree the work happened in.
  • Pull request — where reviewers actually look.
  • Linear issue — when Linear is connected; attached at closeout.
  • Automation run — when a dispatched agent or CTO worker captured it.

​
Review states

Every artifact moves through a small set of states so reviewers know what’s been judged:
StateMeaning
PendingCaptured, not reviewed yet (the default).
AcceptedGood evidence for the claim.
Needs moreUseful but incomplete — capture again.
DismissedNot relevant to the final result.
PublishedPromoted to a PR comment or Linear issue.
Accept / request-more / dismiss are first-class controls on each proof in the drawer.

​
The lifecycle

1

Capture

Capture a screenshot, recording, trace, log, or verification note from the relevant chat or lane.
2

Review

Open the proof and decide whether it supports the work — accept, request more, or dismiss.
3

Attach

Link accepted proof to the PR, Linear issue, lane, or chat. The same artifact can ride along to several owners at once.
4

Reference

Use the proof during review so the result is inspectable, not just asserted.

​
Good proof habits

  • Capture after the relevant change is visible, not during the work.
  • Write a caption that names the exact state being proven — “checkout succeeds, confirmation visible,” not “screenshot 3.”
  • Keep a set to three to eight captures a reviewer can read in one pass; avoid dumping a screenshot after every click.
  • Attach test output or a verification note when the proof is about correctness.
  • Dismiss proof that no longer supports the final result, so the record stays honest.
For a reviewer, the strongest PR pairs a visual proof with a short verification note: a screenshot of the result plus one line on what was checked and why it passed.

Proof overview

What proof is and why it matters.

Proof configuration

Storage, retention, and troubleshooting.