Deciduous
Decision graph tooling for AI-assisted development. Track every goal, decision, and outcome. Survive context loss. Query your reasoning.
See It In Action
Browse the Live Decision Graph — 1,100+ decisions from building deciduous itself
Interactive Tutorial — Learn the workflow in 15 minutes
Watch the Demo — Full session walkthrough
The Problem
You're building software with AI assistance. The LLM generates complex code fast. But then:
- Sessions end. Context compacts. The LLM loses memory of what was tried.
- Decisions evaporate. Six months later, no one remembers why you chose approach A over B.
- PRs become incomprehensible. A 50-file diff tells you what changed, not why.
- Onboarding is archaeology. New teammates reverse-engineer decisions from code.
The code tells you what. But decisions tell you why.
The Solution
Deciduous creates a persistent, queryable graph of every decision made during development. Log decisions in real-time—as they happen—and they survive session boundaries, context compaction, and human memory.
1,174 nodes • 1,024 edges • Real development history from building this tool
Both you and your AI assistant can:
- Query past reasoning before making new decisions
- See what was tried and what was rejected
- Trace any outcome back to the goal that spawned it
- Recover context after sessions end or memory compacts
This isn't documentation written after the fact. It's a real-time record of how software gets built.
Several Agents, One Graph
Ten Claude Code sessions, started at the same second in ten git worktrees of one repository, each building a Tetris from nothing, all logging to one shared deciduous workspace and told to read each other's code and reasoning. Twenty-six minutes later: ten playable games, 386 graph nodes, 170 borrowed ideas with provenance. One finding (some SRS kicks lift a piece two rows, so two hidden rows refuse a legal rotation at the ceiling) reached eight of the nine other branches in eighteen minutes (agent-1 started with a forty-row board and never needed it), and two of the agents that took it used it to find the same silent bug in their own merge().
The arena write-up · the repository · how it works
What made it work is one server, reachable over MCP from every directory, with the branch as the unit of coordination:
- Locks. Every write claims an advisory lock on
(workspace, branch)with a ten second lease. Ten agents on ten branches never wait for each other; two on one branch are told who is there.check_activityreports the holders and the last node on each of the twenty most recent branches. - Events. Postgres triggers push every write over a WebSocket the moment it lands.
deciduous remote watchprints one quoted line per write; Claude Code'sMonitortool can sit on the same URL. - Provenance. A
took_fromedge records a borrow across branches, andlog_observationwrites the observation and the edge in one call. In the arena the borrows lived in observation titles and had to be recovered with a regular expression; that is the wrong place for them.
Set it up with deciduous remote init <url> once the server is running (deciduous_mcp/DEPLOY.md).
First-time setup
Every project writes to a shared graph server, and deciduous init does not
finish until the project points at one that answers.
1. Install the binary (1.0.5 or newer), and Docker:
# or
Docker Desktop (or Docker Engine with Compose) must be installed and running, unless you only use a server someone else runs (step 2b).
2a. Set up a project on this machine's server:
init writes the slash commands, skills and a CLAUDE.md section, then sets
up the server. The first time on a machine, it downloads the server bundle for
its own version and checks it against the release's checksums. It then starts
PostgreSQL 17 and the server on 127.0.0.1:4000 with Docker (a few minutes for
the first build). It stores the token in ~/.config/deciduous/credentials
(mode 0600), and registers the server with Claude Code. Every later project on
the machine finds the running server in about a second. Commit the project
files (by path, not git add -A) so every clone gets them.
To choose interactively instead, run deciduous remote setup. It asks whether
the graph lives on this machine or on a server someone else runs, then does the
rest (--local or --url <url> answer the question in a script).
2b. Or point the project at a team's server before running init:
3. Restart Claude Code. When it connects, the server sends the logging
instructions (when to write, and how to write one step in one call). There is
no hook to install. Agents write through the MCP tools. deciduous add from
the CLI writes to the local database until you run deciduous remote push.
If anything is missing (no Docker, a server that does not answer, no token),
init and update stop with exit 1 and say how to fix it. Upgrading later is
brew upgrade deciduous or the same cargo install line, then
deciduous update in each project (deciduous update --all ~/code for many).
4. See several agents work together (macOS, in iTerm2 or Ghostty):
--ask keeps Claude Code's permission prompts in every pane. After
deciduous update, Claude Code also has it as /demo-swarm.
Written for the agent doing the setup rather than for you: deciduous.dev/agents/ and deciduous.dev/llms.txt.
Installation
Homebrew (Recommended)
Pre-built Binaries
Download the latest release for your platform from GitHub Releases:
| Platform | Binary |
|---|---|
| Linux (x86_64) | deciduous-linux-amd64 |
| Linux (ARM64) | deciduous-linux-arm64 |
| macOS (Intel) | deciduous-darwin-amd64 |
| macOS (Apple Silicon) | deciduous-darwin-arm64 |
| Windows | deciduous-windows-amd64.exe |
# Example: Linux/macOS
Self-host the shared graph server
Download and extract deciduous-mcp-docker.tar.gz from
GitHub Releases,
then run:
Docker with Compose is the only runtime prerequisite. Setup creates private
credentials, starts PostgreSQL with persistent storage, applies migrations, and
waits until the server can query the database. Your MCP endpoint is
http://127.0.0.1:4000/mcp; its bearer token is in .env. Running setup again
keeps the same credentials and database.
Already have a Deciduous PostgreSQL database? The same setup can connect to it
and apply pending migrations. See the deployment guide
for that path, client configuration, backups, and upgrades. From a repository
checkout, run ./deciduous_mcp/scripts/setup.sh.
Releases also include Burrito-built deciduous-mcp-* native executables with
Erlang/OTP and Elixir included. The deployment guide covers their one-time
STRUCTURE.sql bootstrap, which requires PostgreSQL 17+ and psql 17+.
Via Cargo
From Source
# Binary at target/release/deciduous
Quick Start
# Initialize in your project
# Start logging decisions
# View the graph
That's it. Your first decision graph is live.
The Canonical Flow
Every decision follows this path through the graph:
goal → options → decision → actions → outcomes
- Goals lead to options (possible approaches to explore)
- Options lead to a decision (choosing which option to pursue)
- Decisions lead to actions (implementing the chosen approach)
- Actions lead to outcomes (results of the implementation)
- Observations attach anywhere relevant
- Revisits connect old approaches to new ones when you pivot
Multi-Assistant Support
Deciduous integrates with multiple AI coding assistants:
# Claude Code (default)
# OpenCode
# Windsurf (Codeium)
# Multiple assistants
| Assistant | Flag | Integration Files |
|---|---|---|
| Claude Code | --claude (default) |
.claude/, CLAUDE.md |
| OpenCode | --opencode |
.opencode/, AGENTS.md |
| Windsurf | --windsurf |
.windsurf/hooks/, .windsurf/rules/ |
Auto-detection: deciduous update auto-detects which assistants are installed (.claude/, .opencode/, .windsurf/) and updates them all. Windsurf is also auto-detected during init if .windsurf/ already exists.
MCP Server
Deciduous includes a built-in MCP server that works with Claude Code, Claude Desktop, and any MCP-compatible client. Instead of shelling out to the CLI, the AI gets direct access to 32 tools for managing and querying the decision graph. The shared graph server is a second endpoint, over HTTP, with 18 tools of its own and the multi-agent ones (check_activity, branch on every write, took_from) live there.
Claude Cowork: Coming soon. Cowork agents can't yet load custom MCP servers — track progress on anthropics/claude-code#48909.
Claude Code (this project's local database, over stdio):
Claude Code reads MCP servers from claude mcp add (or a project .mcp.json),
not from .claude/settings.local.json. For the shared server, see step 4 of
First-time setup.
Claude Desktop:
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
Use the absolute path to the deciduous binary (run which deciduous to find it) — Claude Desktop doesn't inherit your shell PATH. Point DECIDUOUS_DB_PATH at the SQLite database in your project's .deciduous/ directory, then restart Claude Desktop.
Claude Code (user-level):
Add --scope user to the claude mcp add line to make the server available in every project.
Once configured, the AI gets tools for:
| Category | Tools | What they do |
|---|---|---|
| Graph CRUD | add_node, link_nodes, delete_node, ... |
Create and manage decision nodes and edges |
| Querying | list_nodes, search_nodes, show_node, ... |
Find and filter nodes across the graph |
| Analysis | trace_chain, get_node_context, get_pulse, ... |
Traverse chains, get neighborhood context, find orphans |
| Sessions | start_session, end_session, resume_session, ... |
Each conversation gets its own decision tree |
| Export | export_dot, generate_writeup |
DOT visualization and PR writeups |
Sessions persist to disk and auto-resume across server restarts, so long-running conversations keep their decision trees intact.
Full MCP documentation and tutorial
The Workflow
BEFORE you do something → Log what you're ABOUT to do
AFTER it succeeds/fails → Log the outcome
CONNECT immediately → Link every node to its parent
Example Session
# Starting a new feature
# Considering options
# Attach the design spec to the goal
# Making a choice
# Implementing the chosen approach
# Attach the architecture diagram to the action
# Recording the outcome
# Share it: .deciduous/graph.json is written as you go;
# sync imports teammates' records into the local database
Document Attachments
Attach files to any decision node — architecture diagrams, specs, screenshots, PDFs.
# Attach a diagram to a goal
# AI-generate a description
# List what's attached
# Open a document
# Soft-delete (recoverable)
# Clean up orphaned files
Documents are stored in .deciduous/documents/ with content-hash naming for deduplication. The web viewer displays attached documents in the node detail panel. Soft-delete with doc detach; garbage-collect orphaned files with doc gc --dry-run to preview.
Session Recovery
When context compacts or you start a new session:
Or open the web viewer and ask a question in plain English:
"What was I working on before the session ended?" "What approach did we take for rate limiting and why?"
The graph remembers what you don't. The Q&A interface lets you ask it.
Skills: Archaeology, Decision-Graph, and Narratives
Deciduous ships with skills that give your AI assistant structured ways to understand and work with a codebase's decision history.
/decision-graph — Visiting and documenting the past
The /decision-graph skill builds a full decision graph from your repository's commit history — perfect for bootstrapping a graph on an existing project that wasn't using deciduous from the start. It works in four layers:
- Commit analysis — Groups commits into logical narratives
- Code structure — Identifies architectural decisions from the codebase
- Narrative construction — Builds evolution stories with pivots and connections
- PR context — Uses
ghCLI to mine PR descriptions and review threads for decision rationale, alternatives considered, and trade-offs discussed
/archaeology — Revisit, correct, execute
Archaeology is for revisiting past decisions in the graph—finding what went wrong, correcting the record, and executing on a new direction. When you discover a past decision was flawed, archaeology gives you the workflow to trace it back, mark it superseded, and connect the new approach.
# Find the old decision and mark it
# Revisit: pivot from old approach to new
# Execute the new direction
After archaeology, you can query: "What did we try before?" (--status superseded), "What led to this decision?" (edges --to <id>), "What are the pivot points?" (--type revisit).
/narratives — Understand how the system evolved
Narratives are the conceptual stories—how a subsystem evolved over time, what pivots happened, and how different parts of the system connect.
**Current state:** JWT for API, sessions for web.
**Evolution:**
1. 2.3.
**Connects to:** "Rate Limiting"
Output: .deciduous/narratives.md with evolution stories that archaeology can transform into graph structure.
/pulse — Map the current design
Pulse maps the current architecture as a decision tree — the design choices that make the system work today. Your agent reads the code, identifies the design questions that had to be answered, and logs them as nodes. Useful for understanding what decisions you might affect before making changes.
Deep Q&A Interface
The web viewer includes a built-in Q&A interface where you can ask questions about your decision graph and get answers grounded in your actual development history.
POST /api/ask
{
"question": "Why did we switch from JWT to sessions for web auth?",
"context": {
"selected_node_id": 42,
"branch": "main"
}
}
The Q&A system:
- Sends your question + graph context to Claude — it sees the relevant nodes, edges, and narrative context
- Archaeology-aware — when asking from the archaeology view, the agent gets full narrative context including pivots, superseded approaches, and GitHub links
- Stores every interaction — questions and answers are saved with full-text search (FTS5), so you can search past Q&A sessions
- Searchable history —
GET /api/qa/search?q=authfinds past conversations about authentication decisions
This turns the graph into a conversational interface. Instead of manually traversing nodes, ask: "What was tried before the current approach?" or "What connects the auth system to rate limiting?"
# Browse Q&A history
&limit=20
# Search past questions
&limit=10
# Get a specific interaction
Viewing the Graph
Web Viewer
Five views:
| View | Purpose |
|---|---|
| Chains | Decision chains by session—see the story of a feature |
| Timeline | Chronological view merged with git commits |
| Graph | Force-directed interactive visualization |
| DAG | Hierarchical goal→decision→outcome flow |
| Archaeology | Narrative-driven exploration with Q&A |
Features: branch filtering, full-text search with type filters, resizable panels, deep linking, click-to-expand details, keyboard navigation (j/k/g/G/Space), Q&A panel, and auto-refresh.
Node Types
| Type | Purpose | Example |
|---|---|---|
goal |
High-level objective | "Add user authentication" |
option |
Approach considered | "Use JWT tokens" |
decision |
Choice point | "Choose auth method" |
action |
Implementation step | "Added JWT middleware" |
outcome |
Result | "Auth working in prod" |
observation |
Discovery or insight | "JWT tokens too large for mobile" |
revisit |
Pivot point—connects old approach to new | "Reconsidering token strategy" |
Node Status
| Status | Meaning |
|---|---|
active |
Current truth—how things work today |
superseded |
Replaced by a newer approach |
abandoned |
Tried and rejected—dead end |
Edge Types
| Type | Meaning |
|---|---|
leads_to |
Natural progression |
chosen |
Selected this option |
rejected |
Did not select (with reason) |
requires |
Dependency |
blocks |
Preventing progress |
enables |
Makes possible |
supersedes |
New approach replaces old (via revisit) |
Graph Maintenance
Made a mistake? Fix it:
# Remove an edge
# Delete a node (cascades to connected edges)
# Preview before deleting
Keeping AI Integration Updated
When deciduous releases new features, your existing projects can get the latest integration files:
# Check if an update is needed
# Update integration files (auto-detects installed assistants)
The update command auto-detects which assistants are installed and updates them:
Claude Code (.claude/)
| Files | What's Updated |
|---|---|
.claude/commands/*.md |
Slash commands (/decision, /recover, /work, /document, /build-test, /serve-ui, /decision-graph, /sync) |
.claude/skills/*.md |
Skills (/pulse, /narratives, /archaeology) |
.claude/hooks/version-check.sh |
Once-a-day update check (the logging hooks earlier versions installed are removed) |
.claude/agents.toml |
Subagent configurations |
CLAUDE.md |
Decision Graph Workflow section (preserves custom content) |
OpenCode (.opencode/)
| Files | What's Updated |
|---|---|
.opencode/plugins/version-check.ts |
Once-a-day update check |
.opencode/commands/*.md |
Command templates |
.opencode/skills/*/SKILL.md |
Skill definitions |
.opencode/agents/*.md |
Custom deciduous agent |
.opencode/tools/*.ts |
Custom deciduous tool |
.opencode/opencode.json |
Plugin configuration |
AGENTS.md |
Decision Graph Workflow section |
Windsurf (.windsurf/)
| Files | What's Updated |
|---|---|
.windsurf/hooks.json, .windsurf/hooks/version-check.sh |
Once-a-day update check |
.windsurf/rules/deciduous.md |
Always-on rules for Cascade |
Kept: anything deciduous did not write. A file you changed is left alone (Markdown gets the new text appended in a marked block), everything update changes is backed up to .deciduous/update-backups/<time>/ first, and .claude/settings.json only loses the deciduous log-loop entries. .deciduous/config.toml and docs/ are not touched.
Automatic Version Checking
Deciduous always checks crates.io for new versions once per 24 hours via a lightweight hook. The notification varies by severity:
- Patch updates (e.g., 0.13.10 → 0.13.11): quiet one-line notification
- Minor/major updates (e.g., 0.13.x → 0.14.0): prominent banner encouraging upgrade
You can also check manually at any time:
The check is rate-limited (once per 24h), has a 3-second timeout, and never blocks your workflow. Results are cached in .deciduous/.latest_version.
Why there are no logging hooks
Up to 1.0.2, deciduous installed a hook that denied an agent's next tool call
until it wrote to the graph. It could leave a session unable to do anything:
a graph write sent beside the next action did not count, a session whose
settings changed underneath it could not reset the count, and an environment
variable typed into the session never reached the hook. 1.0.3 removes it, and
deciduous update takes it out of projects that have it. The only hook left is
the once-a-day version check, which never blocks.
Logging is encouraged by what the agent reads anyway: the CLAUDE.md section,
and the MCP tools' own descriptions and replies.
The Premises
-
Decisions are the unit of institutional knowledge. Code tells you what, but decisions tell you why. Six months from now, you won't remember why you chose Redis over Postgres for that cache. The graph will.
-
Structured thinking produces better outcomes. The act of logging a decision—naming it, assigning confidence, connecting it to goals—forces you to think it through.
-
Real-time logging beats retroactive documentation. Capture reasoning in the moment. By the time you write post-hoc docs, you've forgotten the options you rejected.
-
Graphs beat documents. Goals spawn decisions, decisions spawn actions, actions produce outcomes. A graph captures these relationships. You can trace any outcome to its origin.
-
Complex PRs tell a story. A 50-file diff is incomprehensible. A decision graph shows the goal, the key decisions, the rejected approaches, and how each change connects to purpose.
-
Context loss is inevitable. Sessions end. Memory compacts. The graph survives.
-
The graph is a shared workspace. Decisions flow between sessions, between humans and AI, between teammates. The graph doesn't care who's typing—it preserves the reasoning.
Commands Reference
# Initialize
# Add nodes
# Node options
|
# Connect and disconnect
# Delete nodes
# Query
# Visualize
# Sync + export
# Document attachments
# Shell completion
Who Uses Deciduous
You, the developer:
- Think through decisions by structuring them
- Remember why you made choices months later
- Review PRs by understanding the decision flow
- Onboard to codebases by reading decision history
- Ask questions about your own project's history and get grounded answers
Your AI assistant:
- Recover context after compaction or session boundaries
- Build on previous reasoning instead of starting fresh
- Leave a queryable trail for future sessions
- Use
/archaeologyto revisit and correct past decisions - Use
/decision-graphto build decision graphs from commit history - Use
/documentto generate comprehensive docs with test examples - Ask deep questions via the Q&A interface grounded in actual graph data
- Attach relevant documents (diagrams, screenshots, specs) to decision nodes
Your team:
- Share decision context through
.deciduous/graph.json, one git-tracked file; concurrent edits merge record by record - Review PRs with full visibility into reasoning
- Build institutional knowledge that survives turnover
- Search past Q&A interactions to find answers that were already given
Why "deciduous"?
It almost has the word "decision" in it, and they're trees.