🌳 discussion-tree
discussion-tree turns a single Claude Code session into a structured, parallel decision tree.
CLI is serial. The moment you have three things to figure out at once with Claude Code, the conversation has to interleave them — and somewhere along the way, context drifts. discussion-tree lays the questions out as a mind-map in the browser: each item gets its own card, you answer each one independently, and Claude Code receives every answer back through the MCP channel. The CLI side stays linear; the user side gets to see "which thread is this?" at a glance.
Key features
- Parallel decisions inside a single CC session. Not multi-instance orchestration — just splits one Claude Code session's discussion into independent settle-able branches. Each board = one actionable feature / decision.
- Three surfaces: boards, maps, checklists. A board is the converge-and-decide surface (a concern → item tree you settle one card at a time). A map is the diverge-and-explore surface that comes before a board (a free-form graph of cards you and Claude co-build spatially). A checklist is a node that tracks items with a status each (decisions, acceptance criteria, work steps) — Claude keeps it current. See Concepts and Using it.
- DB-backed context that doesn't evaporate. Every board, node, status change, and message is persisted in SQLite. You can revisit a discussion from last week and Claude Code can re-read its own past reasoning, same as you do — the project becomes a permanent shared memory rather than a stream of CLI turns lost to scrollback.
- Mobile / off-device access via Tailscale Serve. Open the same board UI from your phone on the train, answer a node, and the next CC turn picks up your reply on the desktop. The broker stays bound to localhost; Tailscale handles the network and auth.
- Live UI. WebSocket pushes — node status changes, Claude's incoming replies, the working badge from the PreToolUse hook — repaint instantly across every open tab and device.
- Default conversation board. Each CC session auto-gets a chat-style board so you have a casual surface for "talk to Claude in the browser instead of CLI" without creating a structured board first.
- Optimistic submit + delivery confirmation. Posting from the UI shows a tentative card immediately; the broker blocks until the MCP server has actually picked the message up. If CC isn't reachable, the text is preserved in the textarea so you don't lose it.
- Image paste / drop. Screenshots paste straight into the textarea, get uploaded to a per-board directory under
$DISCUSSION_TREE_HOME/uploads/, and the message text includes the absolute path so Claude reads the image with its Read tool before replying.
- Per-device UI settings. Light / dark / system theme, language (English / Japanese / system), auto-mark-as-read, sidebar status filter. Per-device localStorage so your phone and laptop can behave differently.
- Inspired by a broker-daemon + MCP-server pattern. Same broker-daemon-plus-MCP-server topology; the topic split (intra-session, structured) is where discussion-tree diverges.
Concepts
The data model is intentionally shallow. Two structural levels and that's it:
- Session — one Claude Code session_id. Stable across MCP-server restarts via
attach_cc_session. The sidebar groups boards by session.
- Board — one settle-able unit ("1 board = 1 actionable feature / decision"). Each session also gets one auto-created default conversation board (a chat surface with a single fixed node).
- Concern — top-level discussion topic within a board. Visually a column header in the UI.
- Item — a node hanging under a concern. The unit of discussion / decision. Has a status (
pending / discussing / resolved / agreed / adopted / rejected / needs-reply / done) and a thread of messages.
- Thread item — one message in the item's conversation log.
source is user, cc, or system (status-change auto-entries). Has a read_at so the unread dot in the sidebar can light up.
The hierarchy is deliberately exactly 2 levels (concern → items): no sub-items. If a topic feels like it needs nesting, you split it into a separate concern, or split the whole thing into a new board. This keeps the UI readable at a glance and forces "1 decision per node" granularity.
Two more surfaces sit alongside boards:
