feature-tree

Feature Tree

The interface between human intent, AI agent, and code.

Philosophy

The Problem

AI agents are high-variance systems. They can reason, explore, and make decisions. But without context, they:

• Guess instead of knowing
• Duplicate instead of reusing
• Break things they didn't know existed
• Lose everything when sessions restart
• Degrade as context window fills up

Traditional solutions try to control agents with rigid rules. This doesn't work — you can't control a complex system with a simple one.

The Solution

Feature Tree is a semantic layer that grows with your project. Not rules that constrain, but context that enables.

Workflows capture human intent — user journeys explained like you'd explain to a YC partner.

Features capture code reality — atomic units with technical notes for implementation.

Semantic search connects them — "auth" finds login, signin, credentials. Jump straight to context without guessing.

The agent starts at the right zoom level, with the right context in hand.

How It Works

Workflow-First Approach

Task arrives
    ↓
search_workflows("what user wants")  ← Start here (broad context)
    ↓
get_workflow(id) → steps, dependencies, purpose
    ↓
get_feature(id) → files, symbols, technical notes (focused context)
    ↓
Read actual code (only when needed)

One workflow often contains all context needed for a task. No need to grep the entire codebase.

Two Trees, Connected

Tree	What It Captures	Audience
Workflows	User journeys, steps, why it exists	Human (YC partner level)
Features	Atomic code units, how it works	Developer (implementation level)

The link is the power:

• get_feature("AUTH.login") → shows which workflows use it
• get_workflow("USER.login_flow") → shows which features are done vs planned

Field Definitions

Workflows:

• description — Explain to a YC partner (what the journey IS)
• purpose — Technical goal (why it exists in the system)
• steps — Actual flow in plain language

Features:

• description — Explain to a YC partner (what it does, user-facing)
• technical_notes — Explain to a developer (how it works, gotchas)

Both self-contained. Enough detail that Claude can understand without asking questions.

Semantic Search

Search finds related concepts, not just keywords.

search_features("auth")     → finds: login, signin, credentials, session
search_workflows("payment") → finds: checkout, subscription, refund

Jump straight to the right context. Prevents duplicates, prevents hallucination, prevents blind spots.

Installation

/plugin marketplace add github:Nothflare/feature-tree
/plugin install feature-tree@feature-tree
/plugin install ft-mem@feature-tree
# Restart Claude Code

Semantic Search Setup (Optional)

Without API key, falls back to keyword search. Still works, just less semantic.

// ~/.claude/settings.json
{
  "env": {
    "FT_EMBEDDING_API_KEY": "sk-or-..."
  }
}

Env Variable	Default	Description
FT_EMBEDDING_API_KEY	(none)	OpenRouter API key
FT_EMBEDDING_MODEL	openai/text-embedding-3-small	Model
FT_EMBEDDING_ENDPOINT	https://openrouter.ai/api/v1/embeddings	Endpoint

MCP Tools

Search (use BEFORE implementing)

Tool	Purpose
search_features(query)	Find existing features, prevent duplicates
search_workflows(query)	Find user journeys, understand broad context

Get (use AFTER search for full context)

Tool	Purpose
get_feature(id)	Files, symbols, dependencies, what depends on this
get_workflow(id)	Steps, purpose, which features are ready vs blocked

Create/Update (use AFTER implementing)

Tool	Purpose
add_feature(...)	Create new feature
update_feature(...)	Update files, symbols, notes after implementing
add_workflow(...)	Create new workflow
update_workflow(...)	Update steps, dependencies
delete_feature(id)	Archive (active) or delete (planned)
delete_workflow(id)	Archive (active) or delete (planned)

Note: Updates OVERRIDE, not append. To add a file, get current list first, then update with full list.

Usage

Simple Rule

• Search BEFORE implementing (always)
• Create/update AFTER implementing (when you know actual files, symbols)

Status

Status tells you what you CAN DO with something:

Status	Meaning	Action
planned	Designed, not in code	Don't depend on it yet
active	Implemented, working	Safe to use
archived	Deprecated/removed	Update things depending on it

being_modified (for handoff only)

Only set when handing off mid-task: