Flare watches the agent in its terminal and keeps a graph of who changed what

Flare watches the terminal rather than replacing the agent

The framing sentence is that you run the agent in Flare's terminal and Flare watches. That is the whole architecture in one line, and it is what separates this from an IDE with a built-in agent.

You launch claude, codex, or opencode yourself in a full terminal that sits underneath the graph. Flare does not wrap or replace the CLI, which means anything you already do with it keeps working.

What Flare adds is observation. It maps the repository from the source, attributes every write to whoever made it, and pulls you in when something important changes. The stated consequence is that you and the agent are looking at the same project rather than at a chat log.

The board is where that becomes concrete. The agent takes work from the board and asks its questions there, so a request for clarification appears as a card rather than as a prompt you have to notice in a stream of output.

There is also a delivery mode that is not a desktop app at all: the same interface can be served to a browser from the machine the agent runs on, which is the arrangement for an agent on a remote box that you do not have a display for.

The measured example in the readme is Flare opened on its own source, showing 99 nodes and 326 edges.

Write attribution answers mixed rather than guessing between two agents

Attribution is the feature that decides whether the board is trustworthy, and the documented behaviour in an ambiguous case is the interesting part.

The example is an alert Flare raised on its own about a file that nothing covers, shown in the corner of the graph. With a single agent live the answer is straightforward. With two agents live, the attribution reads `mixed` rather than picking one of them.

That refusal is the design. A graph tool that attributes a write to the wrong agent is worse than one that admits it cannot tell, because the whole point of attributing is to decide what to read first.

The same attitude shows up in how the graph is used for impact. The Activity lens shades each file by how recently it changed, and hovering a shared file lights every file that imports it in amber, described as the blast radius of one file without reconstructing it from a grep.

So the graph is not decoration. It answers two questions a terminal cannot: what does this file touch, and who just changed it. The second one is the one that matters when two agents are working at once.

The lens system reinforces it. The same layout can be recoloured by Clusters, Activity, Hotspots defined as churn times complexity, Risk, Tests, Coverage, Instability, Reuse, Unread, or Cycles, with a strip under the toolbar explaining how to read the colours and showing the matching scale.

Every change burst is snapshotted into a local shadow history

As the agent edits files the graph updates in real time, and every change burst is snapshotted into a local shadow history.

Two properties of that history are worth stating separately. It is local, so the record of what an agent did lives on the machine rather than in a service. And it is revertible at either granularity: per file, or as a whole tree.

The unit is a burst rather than a single write, which matches how agents actually work. A refactor is many writes in a short window, and snapshotting per write would produce a history nobody could read. Grouping by burst makes each entry a decision-sized thing you can look at.

The readme describes the intended use as diffing against the history and reverting to it, which is the recovery path for an agent that went somewhere you did not want.

That recovery is what makes the unattended story workable. The premise of the project is a long session you are not watching, so the guarantee you need is not that the agent never goes wrong but that going wrong is cheap to undo.

A per-file revert matters in that context because the agent's blast radius is rarely the file it was asked to edit.

Three views of one graph, chosen for different questions

The graph has three renderings, switchable from the toolbar or the command palette, and each one honours the active lens, the selection, collapsed directories, and the search filter.

Canvas is the default and the most structured. Dependency cards sit on a pannable board ordered left to right by dependency depth, computed by condensing strongly connected components, reducing crossings, and wrapping the result into bands so a long chain never becomes an unreadable strip. Foundations go on the left and entry points on the right. Cards carry the filename, a lens-coloured rail, and badges for complexity, coverage percentage, untested status, TODOs, and cycles. Hovering traces imports in blue and importers in amber, shift-click traces the path between two files, and card positions persist when you drag them. Zooming out swaps the cards for a plate skin, described as semantic zoom, so the shape of the repository still reads.

Wheel puts every node on a single ring ordered by directory, with dependencies crossing the middle as bundled chords. You drag to spin, scroll to zoom, and click a node to pin its dependency directions. The stated purpose is the question Canvas cannot answer: what talks to what across the whole repository at once. A file whose chords fan across the entire disc is load-bearing whether or not anyone documented it that way.

Districts is the fast read on size: a squarified treemap where area is lines of code and shade is the active lens, with selecting a file outlining everything it touches.

A folder with too many files opens into sub-folders, not into hundreds of cards

The layout problem in any codebase graph is the folder that contains everything, and this one has a specific answer.

A folder card holding more files than fit on screen unfolds into its sub-folders rather than into four hundred cards. The example given is a source directory that is 90% of the repository, which therefore has a middle state: it opens into its app, features, and library sub-folders with the dependencies between them drawn, and each of those opens again in turn.

That means the graph has states, not just nodes. Folding it back remembers how far you had drilled, so a view you built up by expanding four levels is still there when you come back.

The discoverability commitments around this are unusually specific. There is a menu bar in the shape of the one you already know from VS Code, with File, View, Graph, Go, and Help. There is a cheat sheet behind a question mark listing every click, drag, and shortcut for the view you are currently in, which is the only version of documentation that stays correct as a UI grows.

And tooltips say what a control does rather than what it is called. Controls that act on the view, meaning pointer mode, centre, fit, zoom, and the cheat sheet, are placed on the corners of the canvas rather than in a toolbar strip above it, so they sit where the thing they affect is.

The task board emits a brief, the named files, and what the graph knows

The control panel has three sections, and the first is a kanban whose cards are written to be handed to an agent.

The primary action on a card is Copy for agent. What it emits is three things: the brief, the files the brief names, and what the graph already knows about those files, given as a fragment like 29 files downstream, 0% covered, in an import cycle.

That third element is the point. The stated rationale is that the agent starts from the map instead of spending half its context rediscovering it, which is a real cost in a token budget and a real failure mode when the agent guesses at impact.

Cards can also be filed straight from a graph selection with a right-click, so the map and the board are connected in both directions.

Lanes are yours to arrange: add, rename, reorder, or remove them, with the detail that removing a lane rehomes its tasks rather than dropping them. Losing a lane is a view preference, not a data loss, and that distinction is what keeps people willing to reorganise.

The design decisions section records architectural calls an agent makes without being asked, such as a module boundary or a data shape that will spread. They are recorded before the code that assumes them and land as proposed, for you to agree or decline with a reason. The rule that an agent cannot agree with its own proposal is the whole integrity story of the feature.

Questions are parked, and the routine stops the agent halting on the first one

The third panel section is questions, and its design decision is that a question is parked rather than blocking.

Each question names the tasks it holds up, so the rest of the board stays workable. The agent picks up something else and halts only when everything left is waiting on an answer. Answer it in the panel and the agent reads it back over MCP.

That is a deliberate departure from the usual failure mode, where an agent that needs clarification simply stops and the operator has to notice. Here the question has a queue position and a cost, expressed as the set of cards it blocks.

The routine wizard covers the other half. It sets what the assistant does when it runs out of work: check the board again rather than stopping, record design decisions you have not agreed to and either keep building on them or park the work that rests on them, and park questions instead of halting on them, plus any house rules you type.

What it produces is the working agreement the agent actually reads. That agreement is generated from the switches, so turning one off removes its rule, and it is editable, on the stated grounds that the switches cover what every project wants and nothing of what yours wants said in its own words.

It is stored with the project, and the tool that returns it also returns the board state: how many cards are waiting to be picked up, how many are in progress, how many are blocked, what is waiting on you, and which card to take next.

The board is queryable over MCP, and the packaging is Windows x64 only

Everything in the panel is reachable from the agent, which is what lets it run its own loop rather than waiting for a human to move cards.

The tools are named for what they do: list tasks, optionally by lane, to pick up work; get a task for the exact brief a human would have pasted; update a task to log progress and move the card to review; create a task to file follow-up work it found but should not do now; record a decision; ask a question; and return the working agreement when it is unsure whether to keep going. Everything shows up in the panel live.

So the board is not a display layer. It is a shared work queue with an API, and the agent and the human are two clients of it.

The packaging is where the documentation is thinnest and the configuration is specific. The application identifier is a dev-scoped one, the product name is the project name, and the build output goes to a release directory. Two native dependencies under one vendor directory are explicitly unpacked from the archive, which is the standard accommodation for a module that loads a native library.

The Windows configuration declares two targets, an installer and a zip, for x64 only, with an artifact name that encodes product, version, platform, and architecture. The installer is not one-click and does not offer a machine-wide install, and it leaves application data behind on uninstall. Other platforms are not declared in the part of the configuration shown, so a build for them is a step you would be taking rather than reading.

Editorial conclusion

Flare fits someone running a long unattended agent session on a real repository who wants to see blast radius and authorship rather than scroll a chat log, since the graph and the mixed-attribution answer are the two things a terminal cannot show you. It does not fit someone who wants Flare to replace the agent, because the agent CLI stays in charge and Flare only observes and negotiates. Before adopting it, check which platform your build targets, since the visible packaging configuration is Windows x64 only, and read the working agreement rather than the switches, because the switches cover what every project wants and not what yours wants in its own words.

Frequently asked questions

Official sources

1. AlgoNoRhythm/Flare on GitHub
2. Issues
3. License: MIT
4. README
5. Releases