Visual review, written for people and read by agents.

A reviewer points at what is wrong on the preview. An agent gets what it needs to fix it.

The Maple overlay on a preview deployment: numbered leaf pins on the page, a comment thread in the corner, and a panel showing the context captured with the selected comment.

The comment is the easy part. The context is what goes missing.

Someone opens the preview link and sees the bug. What they saw lives in a screenshot, a Slack thread and a window size nobody wrote down. By the time it reaches whoever fixes it, most of it is gone, and the fix is a guess at which element they meant.

Four things, and all four together.

Pincushion, Vercel Toolbar, Chromatic, BugHerd and Marker.io each do some of this. None of them does all of it.

Open source

Apache-2.0, with no hosted service to sign up for and no account in the loop. Maple runs inside your own application and stores nothing itself.

A merge gate

CI blocks while a visual comment is open. The check is real, and it is named.

maple/visual-review

An agent loop

The agent reads the comments over MCP, makes the change, and resolves them. The gate clears because the work is done.

Deployed previews, not localhost

Maple runs on the preview URL your CI already builds, so anyone holding the link can leave a comment. A designer, a product manager, a client. A tool that runs against localhost can only ever hear from the person running the build.

A comment arrives with the page it was written on.

Where they pointed: The element, the CSS path that finds it again after a redeploy, and the file and line the JSX tagger resolves it to.
What they were looking at: Window and content width, the breakpoint, the device pixel ratio, the colour scheme, the locale, and which sections of the page were open.
Who wrote it: The reviewer, as your own application already knows them. Maple asks your app who is signed in rather than running an account system of its own.

Maple's detail panel for one comment: who wrote it, whether it is still open, how it is found again after a redeploy, its CSS path, and the window size, breakpoint, pixel ratio, colour scheme and locale it was written at.

Maple stores nothing itself.

You point it at what you already run. A connector is one file of plain Promise-returning methods: no Maple account, no Maple database, and nothing to migrate off later.

my-store.ts

import type { StoreConnector } from "@maple-kit/core/connectors";

export function myStore(options: MyOptions): StoreConnector {
  return {
    name: "my-store",
    async list(query) { /* your rows */ },
    async append(comment) { /* your write */ },
  };
}

There are four kinds, and a connector’s capabilities are exactly the methods it defines. There is no second list saying what it supports, because two lists disagree.

storewhere the comments live
mediawhere a screenshot goes
observabilitywhere a trace is read
identitywho the reviewer is

The capability matrix

The loop

Four steps, and the only one a person has to be awake for is the second.

Mount
One route in your application and one script in the preview build.
Comment
A reviewer opens the preview, points at the thing, and says what is wrong.
Gate
The action writes the comments onto the pull request and holds the merge.
Resolve
The agent reads them over MCP, makes the change, and closes them out.

Pre-release, and honest about which part.

Nothing is published to npm yet. The contracts are stable and implemented, the gate and the agent loop have both run against a real pull request, and the reviewer-facing interface is still being built. The post says what works today and what does not.

Read the intro post GitHub

Three packages

@maple-kit/core
Server SDK, overlay and connector contracts
@maple-kit/cli
The maple command
@maple-kit/mcp
The MCP server an agent talks to