A capture is one moment. A flow is a path: "add a product to the basket and check out", written down as steps, each an action plus what a person should see afterwards.
There are two ways to get one, and they answer different halves of the same problem.
The editor proposes them
The hard part of flows was never recording one. It was knowing where to start, on a product with forty pages, before there was any evidence the effort would pay off — so most projects have none, and then everything that depends on flows existing never happens either.
Run FlowKy: Audit all in VS Code. It reads your routes, keeps the ones that are a path rather than a page — a form, a redirect, something that writes to the server — and writes them to .claude/flowky-suggested-flows.md. On this codebase that is login, register, forgot-password and onboarding first, which is what most people would have recorded anyway.
It also marks which paths a machine must not drive on its own, and it works that out from what the route's code reaches rather than from what its buttons are called. A confirm dialog whose handler charges a card counts as payment whatever the button says — a label cannot tell you that, and a label is what a checklist would have read.
Those are suggestions, not recordings. Nobody walked them, so nothing confirms the steps work, and they live in their own file rather than in FLOWS.md for exactly that reason: FLOWS.md is what an agent treats as what must not break, and an unwalked guess does not get to carry that authority.
The browser records them
Recording happens in the Chrome panel, because that is where a browser is. Press record, do the thing once, stop. Each step captures the action and the selector — never what you typed. The redaction is at the source rather than on the way out, so there is no path where a password exists and is then dropped.
Replaying
Press Run to the next question and the panel performs the mechanical steps in order — clicks, scrolls, navigations — recording how long each one took, and stops at the first step that genuinely needs you.
It stops at exactly two kinds, and both stops are honest rather than timid. A type step has no value to replay, because the recorder deliberately never stored one; inventing a value would make the run prove something that never happened. An assert step *is* the question, and a machine deciding whether the right thing appeared is a guess presented as a result.
So a step it performed is recorded as performed, never as pass. Running to the end and showing a green tick would mean "the clicks landed" while every reader took it to mean "the flow works".
The timing is the part people underrate
Each step records both when it happened and how long it took. The offset tells you where you are in the run; the duration tells you which step got slower. A flow that still passes while its checkout step goes from 0.4s to 4s is a regression that pass and fail cannot see.
Reading them
Flows are read far more often than they are run. Before changing a checkout page somebody wants to know what the checkout flow expects, and that person is usually looking at a screen, not a side panel — so they are listed in the web app too, and synced to .flowky/FLOWS.md for whatever agent is about to touch the code.
That file is the context an agent cannot infer. A coding agent looking at a checkout component has no way to know that step four expects a specific confirmation message, or that the flow is the reason a seemingly redundant field exists.
Assertions are yours
A step can assert that something appears. Whether to add one is a judgement about what actually matters, so FlowKy never adds them for you.
Generating them at scale, from the editor
Three commands in VS Code close the loop the browser panel opens:
FlowKy: Flows — generate from this app writes a brief carrying the exact flow format, the selector ladder and the safety rules — a flow walks up to an irreversible step (payment, delete, sign-out), never through it — then hands it to your own assistant: your agent reads the repository and writes one flow file per user path, starting from the audit's classified candidates when they exist.
FlowKy: Flows — push generated flows validates every file against the same schema the server enforces and saves the good ones to your account, scoped to the workspace's project. A second push skips instead of duplicating.
FlowKy: Flows — check run status reads back what the browser's runs concluded: how many flows, how many never walked, how many failed last time. The walking stays in Chrome — only a browser can click a page, and only a person can judge what appeared.