intertree

merge priority P2 effort M wave 2

What it does: Per its actual files, intertree ships ONE skill (tree) plus two pure TypeScript functions (server/src/discovery.ts = recursive filesystem tree-walk keyed on .beads/.git markers; server/src/signals.ts = per-project signal gathering: LOC estimate, manifest type, git commit recency/count, docs list). It declares 0 commands, 0 agents, 0 hooks, and 0 MCP servers. The tree skill is a 6-step interactive workflow (Scan → Hierarchy Review → Classification → Notion Schema → Register → File Selection) that calls interkasten’s MCP tools (interkasten_scan_preview, interkasten_set_project_parent, interkasten_gather_signals, interkasten_register_project, interkasten_scan_files, interkasten_add_database_property). It owns none of those tools and cannot function without interkasten installed and running.

Rationale: This is a stalled, never-completed extraction, not a mature plugin. The README/AGENTS.md both still reference a skills/layout/ directory that was renamed to skills/tree/ (commit b95caf5) — stale docs. The promised “migrate interkasten_* tools to a dedicated intertree MCP server after DaemonContext decoupling” has not happened; the tools remain in interkasten and the TS functions are unrunnable (no package.json/server wiring, unchanged since e387989). The single skill is internally incoherent: its frontmatter says “visualize hierarchy, use /interkasten:layout for the real thing” while its body IS a full duplicate of /interkasten:layout. Net: intertree is a thin redundant shell around interkasten with zero independent runtime capability. SOTA findings (RAG-MCP / progressive disclosure, agent-skill formalization, graph-based registries) all argue against keeping a second hollow surface that fragments the tool catalog and inflates the marketplace without adding capability. Fold the two pure functions into interkasten (or intermap), retire the duplicate skill, and remove the plugin — or, if the extraction is genuinely wanted, it must actually ship an MCP server, which is a from-scratch effort interkasten already covers.

SOTA gap: Project-hierarchy/registry is a code-reconnaissance + persistent-knowledge concern; the 2026 frontier is graph-structured, queryable registries (GraphRAG / graph-based agent memory; intermap’s working call-graph registry) and RAG-MCP progressive tool disclosure. intertree contributes none of this — it’s an interactive chat-driven Notion-registration walkthrough, not an indexed or programmatically queryable structure. Its pure discovery/signal functions are also dead code: server/ has no package.json, no build config, and no MCP wiring, so they cannot run; they are byte-identical to the extraction commit and never modified since. The genuinely reusable SOTA-aligned idea (a queryable project graph) already lives in intermap.

Redundancy: High and structural. (1) interkasten: hosts EVERY MCP tool the tree skill calls (server/src/daemon/tools/hierarchy.ts + signals.ts), and ships its own working /interkasten:layout skill — intertree’s tree skill frontmatter literally says “use /interkasten:layout instead” while its body duplicates that exact 6-step Notion-registration flow. (2) intermap: already provides a working Go MCP server with project_registry (list/manage tracked projects) and resolve_project (path → project context) plus code_structure — covering the project-discovery/registry concern intertree claims. (3) intersense (exists in interverse/) is named as the domain-detection complement, overlapping the classification step. intertree adds no capability not already present in interkasten or intermap.

Actions:

Merge back into interkasten: move the two pure functions (discovery.ts tree-walk, signals.ts signal gathering) into interkasten’s server (they were extracted FROM interkasten/server/src/daemon/tools/init.ts + signals.ts and are byte-identical), then delete the intertree plugin and remove it from the marketplace — eliminating the duplicate /interkasten:layout-vs-/intertree:tree workflow.
If retention is required instead of merge: actually complete the extraction — add server/package.json + build + an MCP server registering intertree_scan_preview/set_project_parent/gather_signals/etc., and rewrite the tree skill to call those instead of interkasten_* (the README has promised this since 2026-02-25 and it has not shipped).
Either way, fix the stale docs: README.md and AGENTS.md both reference skills/layout/ which no longer exists (renamed to skills/tree/ in b95caf5); the SKILL.md body must stop duplicating the Notion-registration flow it tells users to run via /interkasten:layout.
Resolve overlap with intermap’s project_registry/resolve_project before adding any new registry capability — a queryable project graph already exists there; do not build a second one.