grove

Features

The thought exercise behind Grove and the features that fall out of it.

The thought exercise

What happens if you build an IDE from scratch — today, in 2026 — for agentic workflows?

The premise is that the bottleneck has moved. A few years ago the hard part of software was writing the code. Editors optimized for that: cursor management, IntelliSense, refactor tools, multi-file edits, undo trees. Today, with capable coding agents, the hard part is everything around the writing:

  • Review — reading and understanding code you didn't write, fast enough to keep up with multiple agents.
  • Agentic management — knowing what each agent is doing, what it's stuck on, and when it needs you.
  • Organization — keeping parallel tasks, branches, and conversations from collapsing into a single mess.
  • Context management — capturing the why behind a task (notes, links, prior conversations) so neither you nor the agent loses the thread.

Existing IDEs are built for the old bottleneck. Grove asks what the surface looks like when you build for the new one.

What my workflow used to look like

A few months ago, day-to-day work was just two apps:

  • Cursor for editing code.
  • Terminal for running the server.

That was the whole loop.

What my workflow looks like now

Once agents started doing most of the writing, the apps multiplied:

  • Cursor — but mostly to check out and review code, not write much of it by hand.
  • Multiple terminals — one per task, each running an agent or a server, hard to track which is which.
  • Obsidian — for notes, scratch thinking, links to specs and PRs, anything that doesn't belong in code.
  • Chrome — because I'm now managing many more PRs than before, across tabs.

The closest tool I've found to addressing this is Conductor — it's genuinely good at branch management and per-task conversations. But it still leaves a lot on the table. The review surface, in particular, is built on the same git-diff primitive every other tool uses, and git diffs are inherently bad for understanding code: they show you a few lines on either side of a change, stripped of the surrounding file, with no sense of how the change fits into the larger structure. They were designed for "did the author make a sensible patch?", not "do I understand this code well enough to ship it?"

I wanted to build something different.

The features that fall out

Each of these is a direct response to a pain point above. They are not a feature list bolted onto an editor — they're what the surface looks like once you accept the new bottleneck.

A real IDE, tuned for reading

The volume of code you're reading is higher than it used to be, and you didn't write any of it. So the understanding primitives matter more than the keystroke-shaving ones. Grove keeps a full IDE — Monaco, tree-sitter, LSP — and sharpens what it takes to read:

  • LSP — go-to-definition, find-references, hover, auto-installed per language. See lsp.md.
  • Quick navigation — file tree, project search, file palette, jump-to-symbol. See search.md.
  • Walkthroughs — agent-authored tours of unfamiliar code, anchored across files. See walkthroughs.md.
  • Comments anchored in the diff — review notes that stay attached to lines through rewrites. See comments.md.

You can still edit code by hand whenever you want to. The point isn't to take editing away; it's to stop optimizing the surface as if writing were the bottleneck.

Tasks as the primary unit, with notes and diffs attached

Every piece of work is a task. A task owns its own worktree, its own agent conversation, its own notes, and its own diff against the base branch. There's no "open project" / "pick a branch" / "find the PR" / "find the notes" — they're all attached to the same object. See tasks-and-worktrees.md.

This replaces "Cursor + a terminal + an Obsidian page + a Chrome tab" with a single navigable thing.

In-file diffs, not patch hunks

The diff view shows changes inside the actual file, with the full file as context, not as a +/- hunk floating in space. You can see what the function looked like before and what it looks like after, in place, with the rest of the file around it. Comments anchor to lines in that view. See diff-view.md.

This is the direct answer to "git diffs don't give you the full context of the file."

Unified view across worktrees

When you have 5–20 tasks running in parallel, opening each worktree individually does not scale. Grove renders a unified view across all active tasks against the same base branch — you can see, in one place, every file an agent has touched and jump into the per-task diff from there. See diff-view.md and core-constraints.md for why a single base branch makes this tractable.

This replaces the "many Chrome tabs of PRs" workflow.

Worktree and tree management built in

Worktree creation, refresh against base, archive, and revival are first-class operations in the UI — not shell commands you run in a terminal and hope you didn't typo. See tasks-and-worktrees.md.

Notes as a first-class artifact, per task

Each task has a notes.md (and other non-code files) that lives alongside the worktree. The user can edit it directly, and the agent can read it for context. The notes artifact is the bridge between "what I was thinking about this task" and "what the agent needs to know to do it well."

This replaces Obsidian for the per-task case. Standalone Obsidian still has a role for cross-task knowledge, but day-to-day task context lives in Grove. See markdown-editor.md.

The walkthrough MCP — explain code, not just edit it

It has gotten harder, not easier, to understand code now that agents are writing more of it. The volume is up; the author isn't a teammate you can ping; the patterns shift between runs. We need primitives for understanding code, not just primitives for changing it.

Grove exposes a walkthrough MCP: an agent can be asked to take you through a piece of code — annotating files, leaving inline explanations, linking related symbols — and the result lives in the IDE as a navigable artifact, not as a wall of chat text. It's tied to the same comment/anchor protocol the rest of Grove uses, so walkthroughs survive file rewrites. See walkthroughs.md.

The comments API — a real protocol for human/agent dialogue

Chat is a bad surface for code review. It's linear, it's not anchored to files, and it conflates "let's talk about the design" with "fix line 42." Grove ships a content-anchored, MCP-addressable comment store with threaded replies, agent read cursors, and a dedicated UI on top of the diff view. See comments.md.

This is the central primitive of the product. Everything else (the diff view, the walkthroughs, the agent loop) is built on top of it.

Workflow / task primitives for agents

Beyond comments, the same protocol thinking applies to other agent-facing operations: an agent can spawn subtasks (each with its own worktree), write notes that appear live in your sidebar, and trace runtime values without leaving edits behind — all MCP tools with the same inspectable shape as the comment log. See mcp.md.

The throughline

Each of these features is replacing something I currently do across four apps with something that lives in one surface, designed for the actual job: reviewing and steering parallel agent work. Grove isn't trying to be a better Cursor. It's trying to be the thing you reach for instead of Cursor + terminals + Obsidian + Chrome, when the work you're doing is mostly agentic.