Loom – A Markdown knowledge graph for better coding-agent execution

Hi HN, I built Loom because I wanted less agent tooling, not more.

My coding-agent workflow had outgrown PLAN.md. One file kept turning into the partial spec, research log, task queue, evidence log, review notes, handoff summary, and feature doc. And stratifying it typically ends up in disparate scratch files with no canonicity.

One solution is to add more surfaces: a spec tool, an issue tool, a memory system, a review prompt, a planning plugin, a workflow package. But that brings two problems: There is a lack of genuine cohesion, no emergent knowledge graph. And some tools try to do too much and take over your workflow.

I wanted one repo-native work record/grammar with enough structure for the agent to organize itself.

That became Loom.

If you want to stop reading and try it, the repo has install paths for Claude Code, OpenCode, Codex, Cursor, and Gemini CLI as well as more detailed write up in the README:

https://github.com/z3z1ma/agent-loom

How it works:

You start a task in a Loom-enabled repo.

The agent first asks where the work belongs.

If it needs discovery, it goes to research. If behavior is unclear, it goes to a spec. If sequencing is unclear, it goes to a plan. If work is live, it goes to a ticket. If something was observed, it goes to evidence. If risk needs pressure, it goes to critique. If the project learned something reusable, it goes to wiki.

That project vocabulary is the core of Loom. It's a knowledge graph.

The individual pieces are familiar. Beads has local task memory. Spec Kit has executable specs. Superpowers has development oriented skills. ECC has compounding. GSD has context engineering. Ralph has clean execution loops.

Loom’s contribution is the unification and composition. It gives every kind of work a place in the repo, then teaches the agent how to move between those places.

Once implementation is ready, the parent compiles a packet.

A packet is not just a prompt. It is a bounded worker contract compiled from upstream project state: constitution, initiative, research, spec, plan, ticket, evidence, critique, source context, write scope, verification posture, stop conditions, and output shape.

The worker gets a clean context window, but not an empty one. Less context by volume, better context by shape.

Then the loop runs the other way.

After the worker returns, the parent reconciles the result into the ticket, records evidence, routes critique when needed, and promotes durable learning through retrospectives. A rejected path can move into research. A settled explanation can move into wiki. A clarified behavior can move into a spec. A changed sequencing lesson can move into a plan.

The next packet is better because the project is better.

There is no service, daemon, MCP server, workflow engine, or runtime database. The graph lives in Markdown files. Agents inspect it with normal tools: grep, find, git, cat, awk, sed, and shell pipes.

I would like criticism from people using coding agents on projects that span more than one session. The most useful feedback would be where this feels helpful, where it feels like process, and which project layers are wrong/right.