Your data is yours: open formats for runs and designs

Every run and every design version leaves Kaloko as plain files: HTML, CSS, images, W3C DTCG tokens, YAML scenarios and a canvas that opens from disk.

Kaloko keeps nothing in a format only Kaloko can read. A run, a design version or the whole draft exports as a folder or a zip. You can open it from disk, put it in git, hand it to another tool, or keep it after you leave us.

The problem

Design tools store work in proprietary files. The screens, the tokens and the history can only be read inside the tool, and whoever leaves draws everything again. Test tools, in turn, keep the evidence behind their own viewer.

What changes with Kaloko

Designs are plain web files. A step is index.html with its CSS, JS, fonts and images in a folder. Tokens are W3C Design Tokens (DTCG) JSON. The flow is a qawalk.scenario.v1 YAML file.
Exports open from disk. kaloko export --design writes a version as that folder plus screenshots and a start page; links between steps work from the folder or a zip, no server needed.
Runs come with their canvas. kaloko export --run <id> downloads the run as a zip: run.json, every screenshot and HTML snapshot, the live HTML of design steps, the comments and verdicts, and index.html, the canvas itself, which opens offline.
Nothing locks you in. The portable HTML rules (kaloko design lint) keep designs free of CDNs, storage and absolute URLs, so the same files run in Kaloko, from disk and in any other tool.

How it works

Keep designs portable.
Run kaloko design lint in the project; kaloko sync runs it too and stops on anything that would break.
Export a design version.
kaloko export --design --version 4 --out checkout-v4.zip (or --draft, or the design reference by default).
Open it.
Unzip and open index.html: steps in flow order, each locale's page, the screenshots, tokens.json and scenario.yml.
Export a run.
kaloko export --run 2026-10-02-checkout-1a2b downloads the zip; open index.html in it for the full canvas offline.
Reuse the files.
Put the folder in git, feed tokens.json to Style Dictionary or another DTCG tool, validate scenario.yml with kaloko validate, or start a new draft from it.

Skills and prompts

Export the accepted checkout design as a zip with kaloko export --design and attach it to the release issue.

Check the design folder with kaloko design lint and fix every error and warning before syncing.

What it looks like

The export of v4 is a folder: cart/index.html, cart/cs/index.html, _shared/app.css, tokens.json, scenario.yml, screenshots/cart/en/desktop.webp, kaloko.json and index.html. Double-click index.html, click a step, click *Pay*: the next step opens, straight from disk.

What you get

designs and evidence in formats any tool can read today and in a few years
an offline copy of every run before it expires
prototypes that work in Kaloko, from a zip and in other tools alike

FAQ

Which formats exactly?

HTML, CSS, JavaScript, WOFF2 fonts, PNG, WebP, SVG and other web images, W3C DTCG JSON for tokens, YAML for scenarios and JSON for runs (qawalk.run.v1, documented in the package's schemas/).

Can I open an export without Kaloko installed?

Yes. Every export is static files. The run canvas and the design start page are single HTML files that work from file://.

What about the live interactive pages?

They are in the export as the files the designer wrote. Links between steps are plain relative links, so the prototype clicks through from the folder; on the canvas the same files play in the full-screen prototype view.

Which cookies does the website set?

Besides the cookies needed to sign in and to remember your language, the website sets two first-party cookies for 30 days: kl_v (which headline of the homepage you saw) and kl_utm (the campaign parameters of the link that brought you and the first page you opened). They tell us which headline and which campaign brought a visitor; they are not shared with any third party and not used for advertising. If you create an organization, these two values are stored with it.

More guides

Accepting a task with an AI agent, in the pull request Regression before a release: compare the run with the accepted baseline SEO and landing-page checks on production, read-only, every day E-mail flows: capture the message next to the screen that sent it