Skip to content

features

Flows: recording what must keep working

Two ways to get a flow — proposed from your code, or recorded by walking it — and what replaying one tells you.

A flow is a path through your product that has to keep working: sign up, add to basket, check out. Recording one gives you something to check a change against.

Two ways to get one

The editor can propose them. Run FlowKy: Audit all in VS Code and it reads your routes, keeps the ones that are a path rather than a page, and lists them in .claude/flowky-suggested-flows.md. That solves the awkward part — knowing where to start on a product with forty pages, before you have any evidence the effort pays off.

Those are suggestions. Nobody walked them, so nothing confirms the steps work.

The browser records the real thing. In the Chrome panel, press record, do the thing once, and stop. The panel captures the action and which field — never what you typed. A walkthrough of a signup form would otherwise carry somebody's password into a database, so the value is dropped where it is read rather than later on.

Replaying it

Run to the next question performs the mechanical steps in order and stops at the first one that needs you — a value to type, or a judgement to make. It records how long each step took, and a step it performed is marked performed, not pass: nobody looked at it, and the run does not pretend somebody did.

What it is for

When someone — you, a seller, or an agent — changes something nearby, the flow is the thing you replay. It is far cheaper than finding out from a customer that checkout broke on Tuesday.

The timing matters more than it sounds. A flow that still passes while its checkout step goes from 0.4s to 4s is a regression that pass and fail cannot see.

What it is not

A flow is not a test suite and does not replace one. It records what a real path looked like when it worked, which is exactly the context missing from a bug report that says "checkout is broken".