Your agent can't see the page.
So point at the element.
Coding agents read source, not pixels. The reliable fix is to stop describing UI problems in prose and hand the agent a task captured from the live page: the element's exact CSS selector, its source file and line number, the viewport — and a screenshot. Vibeflow captures all of it the moment you click the element.
The problem
Prose is a lossy interface.
Ask a coding agent to “fix the signup button on mobile” and three things go wrong: it guesses which element you mean, it searches for where that element is defined, and it cannot check the rendered result. Every wrong guess is a round trip.
The Vibeflow README puts it plainly: “Describing a UI issue in prose wastes tokens and produces wrong fixes.” The sentence “the button in the top right” contains no selector, no file and no breakpoint — the agent has to reconstruct all three from context it does not have.
- No selector — “the button in the top right” matches several elements on a real page.
- No source location — the agent greps for the label text and finds the wrong file.
- No viewport — “on mobile” without a width is a bug report nobody can reproduce.
One click
What a single annotation captures.
Press Alt+A, click the element that is wrong, type one line. Hovering shows the selector before you commit — what lands in the task is structured, not described.
This is the whole exchange: you point once, and the agent receives fields instead of adjectives. Every value below is machine-readable — it goes straight into a patch, a grep or a selector query, with nothing to interpret.
-
Versioned with your code — tasks are plain JSON files in
.vibeflow/, diffed in review. - No cloud — the server is local, the overlay talks only to your machine, no account is required.
The workflow
From click to merge.
Click it. Name it.
Annotation mode on, element clicked, one line of description and
a priority. The task is written straight to
.vibeflow/ and appears on the board
immediately — no upload, no issue tracker round trip.
The task is a file in your repo.
Because tasks are JSON next to your code, they survive branches, show up in review like any other change, and can be read by anything that can read a file — CLI, HTTP API, MCP client.
Your agent picks it up.
One command claims the highest-priority todo task atomically and prints it with its full context — selector, file, line, screenshot. Implement, then send it to review with a report. Several agents can run in parallel; the atomic claim keeps them off each other's tasks.
Why it works
Structure beats prose, field by field.
- Exact selector — the agent edits the right element on the first try instead of guessing from a description.
- Source file and line — no “where is this defined?” round trip; the answer is already in the task.
- Screenshot and viewport — the visual context and the breakpoint that reproduces it.
- Status and comments on the task — the discussion stays attached to the work, not in chat history.
- Root and child tasks — split an epic into claimable units; several agents work in parallel.
-
Git-native storage —
.vibeflow/travels with the code; there is no cloud to sync or trust.
Start with one command.
No account, no cloud, no browser extension. Start the board,
drag the bookmarklet from /inject to
your bookmarks bar, and annotate the next thing that looks
wrong. The
tutorial walks through all three steps.
Questions we get first
FAQ.
Do I need source maps for this to work?
The CSS selector is always captured — that alone disambiguates the element. Component name, source file and line number come for free with React in development mode (next dev) or any build that ships source maps; without them everything still works, you just supply the file by hand.
Does it work with my framework?
Anything that renders in a browser: React, Vue, Svelte, Next.js or plain HTML. The overlay is a script tag (or a bookmarklet), not a framework plugin — there is no browser extension and no build step.
Where do the tasks live?
In .vibeflow/ inside your repository — plain JSON files, one per task. They diff in review, travel with your code and need no account or cloud service.
How does my agent receive the task?
It asks. tasks --next claims the highest-priority todo root atomically and prints it with its children — the same line works in Claude Code, Cursor, Copilot or any agent that can run a command. If your client speaks MCP, the MCP endpoint exposes the same operation as a claim_next_task tool.
Related pages
Where to go next.
- How to use Vibeflow — the three-step workflow in ten minutes
- vibeflow tasks — every flag of the claiming command
- vibeflow kanban — start the board and the overlay
- MCP setup guide — the same workflow over Model Context Protocol
Ten seconds to your
first annotated task.
No account, no cloud, no browser extension.
Apache-2.0 · Node.js 22+ · tasks stay in your repository