tasks and flows

Flows: writing down what must keep working

Recording the paths through your product that a change must not break.

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.

Recording one

Flows are recorded in the browser extension, because that is where a browser is. Press record in the panel, do the thing, stop. Each step captures what you did and what was on screen.

Reading one

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, with their steps and the timestamp of the last run.

Why this is worth the effort

It 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. A recorded flow tells it, in the agent's own terms, before it changes anything.

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.