Skip to content

reslava/loom

Repository files navigation

🧵 Loom

Your AI agent's long-term memory.

Loom is a document-driven workflow system that gives AI agents persistent context, structured workflow state, and approval gates — so multi-session development stays coherent.

"AI agents are stateless. Loom is the memory layer that makes them not."


The Problem

AI-assisted development degrades over time. Session 1 is the best session — the AI is aligned, decisions get made, code gets written. By session 10, the AI has forgotten everything from sessions 2 through 9. You either re-explain context every time (expensive) or the AI makes suggestions that contradict earlier decisions (damaging).

The cause isn't model quality — it's that there's no persistent memory of what was decided and why.


What Loom Does

Loom stores project memory as a typed, linked markdown document graph:

weaves/
  {weave}/                     ← workstream (e.g. "auth", "payment-system")
    ctx.md                     ← AI-generated weave summary
    {thread}/                  ← feature thread
      {thread}-idea.md         ← raw concept
      {thread}-design.md       ← design decisions and conversation log
      plans/
        {plan-id}.md           ← implementation steps table
      done/
        {done-id}.md           ← post-implementation summary
      ctx/                     ← AI-generated thread summary
      chats/                   ← AI conversation logs
weaves/ctx.md                  ← global project summary (read first every session)
references/                    ← static architectural facts (architecture.md, etc.)

Every document has typed frontmatter. Status is derived from documents — there is no central state file. Changes are versioned in git.


How AI Agents Use Loom

Loom exposes its document graph as an MCP server (Model Context Protocol). Any MCP-compatible agent — Claude Code, Cursor, Continue, Cline — can read and write Loom state via standard tools.

{
  "mcpServers": {
    "loom": {
      "command": "loom",
      "args": ["mcp"],
      "env": { "LOOM_ROOT": "${workspaceFolder}" }
    }
  }
}

The agent owns code execution. Loom owns workflow state. Each stays in its lane.

Key resources (read-only)

Resource What it returns
loom://thread-context/{weaveId}/{threadId} Bundled idea + design + active plan + ctx — the complete "what am I working on" payload
loom://state?weaveId=&threadId= Full project state JSON, filterable
loom://plan/{id} Plan doc with parsed steps array
loom://requires-load/{id} Recursively resolved context chain
loom://diagnostics Broken links, dangling references

Key tools (state mutations)

Tool What it does
loom_complete_step Mark a plan step done (idempotent)
loom_create_idea / design / plan / chat Create Loom documents
loom_update_doc Rewrite doc content, preserve frontmatter
loom_promote idea → design → plan, chat → idea
loom_refresh_ctx Regenerate ctx summary via AI sampling
loom_get_stale_docs List all docs whose parent has been updated since last generation

Key prompts (guided workflows)

Prompt What it does
do-next-step Loads the active plan step + all required context; primary "do work" entry point
continue-thread Loads thread context and proposes the next action
weave-idea / design / plan Guided document creation via AI sampling

The Workflow

1. Idea      → raw concept, rough scope
2. Design    → decisions, trade-offs, rejected alternatives, conversation log
3. Plan      → numbered implementation steps, each reviewable
4. Implement → agent executes one step at a time, marking progress
5. Done      → post-implementation summary, links to what was built

Human approves each phase transition. The agent never advances without a checkpoint.

Staleness detection: when a design is updated, linked plans are flagged stale. The agent sees the warning and knows to re-read the design before implementing. Context can't silently drift.

requires_load: documents declare their own dependencies. Before working on any doc, the agent reads everything in its requires_load chain. It can't miss context it doesn't know exists.


VS Code Extension

The VS Code extension is the human surface over the same document graph:

  • Tree view: weaves → threads → plans, chats, done docs
  • Inline buttons: rename, archive, delete
  • Toolbar commands: Weave Idea, Weave Design, Weave Plan, Start Plan
  • AI buttons (when MCP connected): Weave Idea, Weave Design, AI Reply — powered by MCP sampling

Architecture

cli / vscode / mcp  →  app (use-cases)  →  core (domain) + fs (infrastructure)
  • core: Pure domain logic — entities, reducers, events, validation. No IO.
  • app: Orchestration use-cases. All state changes go through here.
  • fs: Infrastructure — file IO, frontmatter parsing, link index, repositories.
  • cli: Thin delivery layer — command parsing, console output.
  • vscode: Human surface — tree view, commands, toolbar.
  • mcp: Agent surface — MCP resources, tools, prompts, sampling. (v0.5.0)

No layer imports upward. All MCP tools delegate to app — no bypassing.


Status

Feature Status
Core engine (entities, reducers, events) ✅ Shipped
Filesystem layer (repositories, link index) ✅ Shipped
App use-cases (idea, design, plan, step, finalize, rename, archive) ✅ Shipped
CLI commands ✅ Shipped
VS Code extension (tree view, toolbar, commands) ✅ Shipped (v0.3.x)
Global ctx (weaves/ctx.md) 🔧 Planned
MCP server (loom mcp, resources, tools, prompts) 🔧 In design (v0.5.0)
MCP sampling (VS Code AI buttons via agent) 🔧 Planned (v0.5.0)
loom init with CLAUDE.md fusion 🔧 Planned

Quick Start

npm install -g @reslava/loom

# Initialize Loom in your project
cd my-project
loom init

# Create your first idea
loom weave idea "Add Dark Mode" --weave ui

# Check project state
loom status

Why MCP (not a custom AI integration)

MCP (Model Context Protocol) is an open standard for AI agent tool integration — Anthropic-published but supported by Cursor, Continue, Cline, and others. Implementing once exposes Loom to every MCP-compatible agent.

The agent owns code execution, bash, file edits, search — everything a coding agent already does well. Loom owns workflow state. Single billing via the user's existing agent connection. No separate API keys.


References

Document Purpose
Architecture Reference Package relationships, AI integration, frontmatter fields, directory structure
CLI Commands Reference Every loom command
VS Code Commands Reference All VS Code commands and keybindings
Workspace Structure Reference Directory layout and file naming
Claude's Vision of Loom AI perspective on what Loom changes

License

MIT © 2026 Rafa Eslava

About

AI-native workflow engine. Weave ideas into features with persistent Markdown documents and structured AI collaboration.

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Packages

 
 
 

Contributors