Flare

A graph-first IDE for agentic coding — desktop app, or served to a browser from the machine the agent runs on.

The main surface is a live graph of your codebase — every file is a node, imports are edges — with a full terminal underneath where you run claude, codex or opencode. As the agent edits files, the graph updates in real time; every change burst is snapshotted into a local shadow history you can diff against and revert to, per file or as a whole tree.

You run the agent in Flare's terminal, and Flare watches: it maps the repo from the source, attributes every write to whoever made it, and pulls you in when something important changes. The agent takes work from the board and asks its questions there, so the two of you are looking at the same project rather than at a chat log.

What you get

Flare open on its own source — 99 nodes, 326 edges. The Activity lens shades each file by how recently it changed, and hovering shared/graph.ts lights every file that imports it in amber: the blast radius of one file, without reconstructing it from a grep. Bottom right, an alert Flare raised on its own about src/App.tsx — nothing covers it, and with two agents live it says mixed rather than guessing which of them wrote it.

Three views of the same graph

Switchable from the toolbar or the command palette. Each honours the active lens, the selection, collapsed directories and the search filter.

• Canvas (default) — dependency cards on a pannable board, ordered left-to-right by dependency depth (SCC-condensed, crossing-reduced, wrapped into bands so a long chain never becomes an unreadable strip): foundations left, entry points right. Cards carry the filename, a lens-coloured rail and badges (complexity, coverage %, untested, TODOs, cycles). Hovering traces imports in blue and importers in amber; shift+click traces the path between two files; cards can be dragged and their positions persist. Zooming out swaps the cards to a plate skin (semantic zoom) so the shape of the repo still reads.
• Wheel — every node sits on one ring ordered by directory, dependencies cross the middle as bundled chords, and cluster bands are labelled around the outside. Drag to spin, alt+wheel to rotate, scroll to zoom, shift+drag to pan, ctrl+drag to box-select. Click a node to pin its dependency directions; hover a cluster band to isolate that directory; click a band to collapse or expand it.
• Districts — a squarified treemap where area is lines of code and shade is the active lens. The fastest read on "how big is this repo and where does the mass sit"; selecting a file outlines everything it touches.

The Wheel answers the one question the canvas cannot: what talks to what across the whole repo at once. A file whose chords fan across the entire disc is load-bearing whether or not anyone documented it that way. Node dots take the active lens, cluster bands are coloured by directory.

Features

• Folders that open one level at a time — a folder card holding more files than fits on a screen unfolds into its sub-folders, not into four hundred cards. A src/ that is 90% of the repo therefore has a middle state: it opens into src/app, src/features, src/libs… with the dependencies between them drawn, and each of those opens again. Folding it back remembers how far you had drilled.

• Lenses — recolour the same layout by Clusters, Activity, Hotspots (churn × complexity), Risk, Tests, Coverage, Instability, Reuse, Unread or Cycles. Whichever is active, a strip under the toolbar explains how to read the colours and shows the matching scale.

• Everything is discoverable — a VS Code-style File / View / Graph / Go / Help menu bar, a ? cheat sheet listing every click, drag and shortcut for the current view, and a tooltip on every control saying what it does rather than what it is called. What acts on the view — pointer mode bottom-left; centre, fit, zoom and the cheat sheet bottom-right — sits on the canvas corners rather than in a toolbar strip above it.

• Control panel — the collaboration, in three sections. Tasks is a kanban of work written to be handed to an agent: a card's primary action is Copy for agent, which emits the brief plus the files it names plus what the graph knows about them ("29 files downstream, 0% covered, in an import cycle"), so the agent starts from the map instead of spending half its context rediscovering it. File a card straight from a graph selection with right-click → New task with these files. Lanes are yours — add, rename, reorder or remove them; removing one rehomes its tasks rather than dropping them.

  Design decisions is for the architectural calls an agent makes without being asked — a module boundary, a dependency taken on, a data shape that will spread, a refactor across several files. It records them with decision_record before the code that assumes them and they land as proposed, for you to agree or decline with a reason; an agent cannot agree with its own proposal. Whether it then keeps building on one or leaves the work that rests on it is your call, set in the routine.

  Questions is what it needs from you, 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.

  All three are queryable over MCP, so an agent can run its own loop: tasks_list (optionally by lane) to pick up work, task_get for the exact brief a human would have pasted, task_update to log progress and move the card to review, task_create to file follow-up work it finds but shouldn't do now, decision_record, question_ask, and working_agreement when it is unsure whether to keep going. Everything shows up in the panel live.

• A routine, so it doesn't stop at the first question — the ⚙︎ Routine wizard 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. It renders the working agreement the agent actually reads — generated from the switches, so turning one off removes its rule, and editable, because the switches cover what every project wants and nothing of what yours wants said in its own words. It stores it with the project, where working_agreement returns it along with the state of the board: how many cards are waiting to be picked up, how many are already in progress, how many are blocked, what is waiting on you, and which card to take next.

  That last part is written for more than one agent at a time. A card is only offered if it is still sitting in the first lane — moving it to in-progress is how an agent claims it, and no agent is ever pointed at a card another one has started.

  The last switch is the one that doesn't depend on the agent remembering any of the others: check the board when it tries to stop. Flare answers your assistant's stop hook with the state of the board, so a session that tries to end while a card is still workable is handed that card instead, by name. It adds a Stop hook to .claude/settings.local.json — local to your machine, not committed — and takes it out again when you switch it off. Only ever once per stop, so a session can always end, and never a card someone else has already started.

  Several agents on one board is the case all of this is built for: the panel and every agent write through one place, and a write made against a board that has moved on since is rebased rather than believed — so a click in the panel cannot delete the card an agent filed a second earlier.

• Channel — a room the agents talk in — several agents on one repo do not collide because they are careless; they collide because nothing tells them what the others are already inside. Each one sees a clean tree, opens the file its task points at, and finds out about the other when you read a diff where two changes have been folded together with no seam.

  Flare cannot lock the file. It watches a filesystem rather than sitting in front of one, so a lock could only be a request an agent is free to ignore — and one that silently fails open is worse than none, because everyone downstream believes it held. What it can do is give them somewhere to talk, and then draw what was said on the map. The Channel tab is that room:

  Claude 2  taking   shared/graph.ts, shared/resolver.ts
                     moving the workspace lookup out of the resolver
  Codex 1   asking   @Claude 2 — is shared/graph.ts free? I need the edge
                     builder for the cycle fix
  Claude 2  done     shared/resolver.ts — all yours
  

  Three habits, and the tool descriptions ask for all three: say what you are taking before you start (`ch