Private visual review before the commit

Catch visual regressions while coding.

Compare generated images with the accepted baseline before you commit. Keep the finished result in shared history.

Your process produces the images. Working Copy reviews them without waiting for CI or a pull request.
No commit needed Replace as you iterate Carry a matching review into the commit
Visual-output workflows

Render, review, fix—before the commit.

Commit Lens is for code that repeatedly produces visual output: charts, plots, PDFs, reports, maps, or deterministic UI. Keep your renderer; add a review loop around the images it already creates.

  1. 1
    YOUR RENDER SCRIPT DEFINES THE SCENARIOGenerate the monthly revenue report

    The script loads fixtures and applies the report's layout, fonts, and chart rules.

    render-report.py
  2. 2
    YOUR RENDERER PRODUCES NAMED IMAGESThe existing render script exports the report pages and charts.

    Load fixtures → render report → export pages → save named images

    report/revenue.png
    report/retention.png
    report/summary.png
  3. 3
    RUN A WORKING COPY REVIEWCommit Lens compares all three images with the baseline. Review the differences, fix problems, and rerun until the result is ready.
  4. 4
    CREATE THE COMMIT, THEN SUBMIT ITS SNAPSHOTCommit the code in Git, then submit the same named images for that commit. Commit Lens adds the snapshot to shared history.
Your renderer owns the data and export. Commit Lens reviews its images in Working Copy before the code is committed, then adds the commit snapshot to shared history.
Lazy snapshotting · visual bisect

Do not render and review every commit.

Commit as often as the work requires while Commit Lens preserves the complete Git graph. Create snapshots only at useful checkpoints, spending less compute, storage, and review time. If a regression appears later, backfill snapshots only at the revisions that narrow the search.

Snapshot coveragemain · 8dd4c10…f91a804
1Keep routine commits lightweightThe accepted snapshot is correct and today’s snapshot is wrong. Four commits between them were made without snapshots or visual review.
2Snapshot the midpointRender and submit one revision halfway through the gap, then compare its snapshot with either captured boundary.
3Backfill only where neededRepeat inside the remaining range until one commit is the first to produce the regression.
correct snapshotregression snapshotno snapshotbackfilled snapshot
First changed at b31d2a7 · 2 snapshots backfilled · 4 routine snapshots avoided A commit without a snapshot remains an honest gap—Commit Lens never treats “not captured” as “unchanged.”
Coding agents

Let coding agents iterate faster—without commits.

Working Copy gives an agent a fast, replaceable review loop while code is still changing. After each edit, the agent renders named images and uses the Commit Lens CLI to submit a new Working Copy snapshot—no commit or CI wait. The CLI returns visual differences and focused crops, so the agent can fix regressions and check again. A person still decides whether the remaining change is acceptable.

Tell us whether this workflow would help your team.
No visual changes

Zero differences—the task is done. On to the next one.

A refactor, framework upgrade, data-layer change, or CSS cleanup should preserve the product's appearance. Working Copy compares the snapshot with the baseline and confirms the result automatically.

Repository privacy

Your repository stays with you. Snapshot and review history live in Commit Lens.

Stored in Commit Lens

Git history metadata. Commit IDs, parent links, and branch names.

Named images. Each snapshot keeps the visual output tied to its code revision.

Review history. Visual changes, decisions, and the approved baseline stay in one shared record.

Stays in your infrastructure

Repository contents. The backend does not connect to your repository; the local CLI supplies Git history metadata.

Test and rendering environment. Scenarios, automation, rendering, exports, and CI run outside Commit Lens.

Unsubmitted output. Commit Lens stores only the named images included in submitted snapshots.

Two independent checkpoints

Explore Working Copy and Commit as separate review paths.

Working Copy demonstrates fast private iteration. Commit demonstrates the durable team record, review, and baseline workflow.

The interactive product walkthrough is available on larger screens. On mobile, here is the complete flow at a glance.

WORKING COPY

Iterate faster without commits

  1. Submit the images from your working tree.
  2. Mark intended changes and regressions.
  3. Fix, render, and check again before committing.
COMMIT

Catch regressions before release

  1. Submit images attached to a commit.
  2. Review differences and record regressions.
  3. Verify the fix and promote the clean baseline.
https://commitlens.app/acme-storefront baseline: —
bash~/acme-storefront⠿⠿
GUIDE

Ship what is next · keep what already works

Move faster without losing confidence in what users see.

Do not let unexpected visual changes enter the baseline without a person making the call.