Shipped with AI. Now let’s actually look at it.

Things that happen

• PR merged at 2:14. Screenshots nowhere.
• The Slovak version exists. Probably.
• Who approved this? The bot did.
• Three agents, four branches, one staging, zero memory of what changed.
• “Works on my machine” is now “works in my context window.”

How it works

1. Acceptance plan

   An ACCEPTANCE.md next to the task says what each screen must achieve. A scenario.yml turns it into steps, branches and criteria the CLI can run.

2. Walk

   A Playwright script, an agent with a browser, or a person walks the flow in a shared browser. Every step is captured the same way: full-page screenshots on desktop and mobile, rendered HTML, console errors, e-mails from the test mailbox.

3. Check

   Countable criteria (elements, texts, prices, metadata, overflow) are checked in the live page with evidence. Criteria that need judgement get a probability from an AI evaluator that reads a reduced text outline of the page; Kaloko turns it into pass, fail or needs review.

4. Canvas and stamps

   The run becomes a canvas: screens, branches, locales, evidence. Reviewers approve a step, return it with a note, or decide a manual criterion. The agent reads the notes with kaloko feedback and fixes them in the next run.

Three stamps. The human is the point.

What the canvas shows

• Desktop and mobile screenshots of every step, e-mails and third-party screens
• Pass, partial or fail per criterion, per locale and viewport, with the evidence
• Page metadata: title, description, canonical, hreflang, Open Graph, JSON-LD
• Branch, commit, author, PR and environment; the scenario’s history and a pixel diff against the baseline
• Replay: step by step with a choice at every decision, for people who do not read canvases
• Links to a specific step and criterion you can send to colleagues

What teams use it for

Fits the tools you already use

• Claude Code and Codexa skill that knows when and how to walk, capture, evaluate and share
• GitHubkaloko share --pr keeps one comment per scenario on the pull request
• CIthe CLI runs headless; a read-only token is enough to read results
• Mobile and desktop appsAndroid over adb, the iOS Simulator, Electron and macOS apps on the same canvas; screens from Maestro, Appium or XCUITest imported with their UI tree (guide)
• MCPruns, feedback, verdicts and the inbox over MCP at kaloko.app/mcp
• E-mail and Slackdigest of what needs you, immediate mail when your run is returned, one Slack channel for the team

For designers: the design development and QA run against

Design the screens of a flow as live HTML with your own agent and skills, together with your team in real time. Accept a version, and every implementation run is checked against it: pixels, structure, tokens and contrast.

How to design with your agent in Kaloko →

Install once, then work through your agent

Kaloko runs where your code and your agent are. The service stores and versions the results, shows the canvas and collects approvals.

1. Add the CLI to the project

   npm install --save-dev kaloko

   Copy

   Needs Node 20 or newer. Update later with npm update kaloko.

2. Create the config and install the skill

   npx kaloko init --agent claude --org <your-org>

   Copy

   The skill is copied to .claude/skills/kaloko. npx kaloko doctor checks Chrome, the config and the token.

3. Create your organization and a token

   Create an organization; you become its admin. The start page offers a tester token in one click, later under Settings → API tokens. Put it into the project .env:

   KALOKO_TOKEN=qwk_…
   TYPESAFE_API_KEY=…   # optional: semantic evaluator

   Copy

Then just ask your agent

The skill teaches your agent the whole loop: it writes the acceptance plan and the scenario from the task, walks the screens, evaluates, shares the canvas, reads what reviewers said and fixes it. You do not type the commands; you review the canvas.

• From a task to a shared walkthrough

  Read the task in docs/tasks/TASK-123, write its acceptance plan and a Kaloko scenario, walk it on local and share the result on the pull request.

  Copy

  Creates ACCEPTANCE.md and qa/scenario.yml, captures every step in each language and screen size, and posts the link.

• Process the feedback

  Go through the open Kaloko feedback on TASK-123: fix what reviewers rejected, run the affected steps again, share, and answer each comment with what changed.

  Copy

  Reads threads with kaloko feedback, resolves them with the commit that fixed them.

• Check a public site

  Draft a Kaloko scenario for https://example.com (home, pricing, contact) with the seo, a11y and perf packs, run it on production read-only and summarise what fails.

  Copy

  Read-only on production; check packs add SEO, accessibility and performance criteria without writing them by hand.

• Keep the history tidy

  Clean up old Kaloko runs of TASK-123: show me what a prune keeping the newest 3 would remove, then do it once I agree.

  Copy

  Always a dry run first; accepted, kept and commented runs stay.

npx kaloko start --scenario docs/tasks/TASK-123/qa/scenario.yml --env local
npx kaloko walk        # playwright steps; agent/manual steps: kaloko capture
npx kaloko evaluate
npx kaloko share --pr
npx kaloko feedback    # what reviewers said, with ids to answer

Data & security

Free stays free. Paid plans start with a 14-day trial: card required, cancel before it ends and nothing is charged. Terms of service.

Pricing

Viewers are free and unlimited in every plan: the people who look must never be the bottleneck. You pay for what you ship: shared runs per month, tester and admin seats, retention and storage. Team and Business start with a 14-day trial. For businesses; prices exclude VAT.

Semantic evaluation is bring-your-own-key in every plan; local previews are always unlimited. Compare all plans →

Questions we get

What comes next

A weekly “what changed” canvas assembled from runs, check packs for SEO and accessibility, and a GitHub check that turns green when the run is accepted. We tell admins before anything changes that affects them.