graft

Muscle memory for AI assistants: the APIs it learns are written as small files into your git, so next time it starts up, it already knows them.

What this is

A thin daemon plus a helpers/ directory. As it works, the agent writes what it learns into that directory as functions, and the daemon commits them automatically. Memory isn't stored in the AI; it lives in your repository, so any AI can pick it up and use it. It ships with a public registry distributed purely via git and four official helpers: GitHub, Linear, Notion, Stripe.

What problem it solves

An AI assistant learned to call GitHub last week; this week, a new conversation starts and it has to figure it out from scratch all over again. The industry's standard answer is a vector database; my answer is what engineers have always done: write code, store it in git. Readable, editable, rollback-able, shareable.

Use case

You ask Claude Code to pull issues from GitHub, and it writes a list_issues helper into helpers/github.py; the daemon commits it automatically. Next week, when a colleague's agent encounters GitHub, graft add grabs it directly.

Highlights

• Line count is a feature: the core is 921 lines, with a hard CI ceiling of 950 lines; every module has a budget. Fixing a bug must reduce or maintain the line count—if lines go up, you haven't found the root cause.
• Checks at the right layer: on load, only the graft contract is checked (generalization notes, cross-service imports, exec/eval), deliberately skipping ruff and mypy so the agent's edit loop isn't slowed down.
• Actually run end-to-end: a single script drives Claude Code through write helper → call → count → commit, with five acceptance gates; only validated against the GitHub API—no overclaiming.

Where it is now

27 commits, 208 tests, archived in July, released under MIT. Before archiving, I wrote a spec arguing that the daemon shouldn't exist, chose not to act on it, and published it as-is.