martin-conur

Kipi — AI skill for Claude Code

AI community

kipi is a single-binary Rust CLI that manages skills and cross-repo knowledge for LLM coding agents (Claude Code, Codex CLI, Kiro, Cursor and any agent that reads SKILL.md / AGENTS.md) across many loc.

How to install Kipi

This entry records only its repository, not the path inside it, so there is no exact command to give. Open martin-conur/kipi and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Kipi does

kipi is a single-binary Rust CLI that manages skills and cross-repo knowledge for LLM coding agents (Claude Code, Codex CLI, Kiro, Cursor and any agent that reads SKILL.md / AGENTS.md) across many local git repositories, without an MCP server or a database.

Alternatives in AI

  • Memory Forge Rs — Stop resetting satisfying AI chats — edit the memory instead 474 ★
  • Agenvoy — Self-hosted AI agent harness in a single Go binary — writes, sandbox-tests and repairs its own tools, and lets 474 ★
  • Octocode — Structural code intelligence for AI agents — semantic search, knowledge graphs, and a built-in MCP server in o 464 ★

README

kipi

kipi gives LLM coding agents (Claude Code, Codex CLI, Cursor, and any agent that reads `SKILL.md` / `AGENTS.md`) a scoped map of all your local git repositories plus your shared skills. It is a single Rust binary. There is no MCP server, no daemon and no database.

![kipi demo: init, scan, sync, tree, explain and where on the example stores](docs/demo/demo.gif)

The problem

You work across many repos, some personal and some for an employer, and every agent session starts out knowing nothing about any of them.

  • Skills get copied into each repo and drift. The code-review skill in one repo is three edits behind the copy in another.
  • Repo A needs to understand repo B, but nothing tells the agent in A what B is or where it lives, so you paste paths and context by hand.
  • Putting everything in every CLAUDE.md fills the context window, and the agent pays for that text on every turn.
  • Work knowledge must never reach a personal repo, and personal knowledge must never reach a work repo.

The idea: a registry, not copies

The agent does not need a curated copy of another repo's knowledge. It needs a map. A one-line registry entry (name, aliases, a reviewed summary and the local path) is enough for the agent to find the real repo and read its code, README and specs, which are always current. kipi keeps that map in plain TOML files called stores, one store per trust boundary (personal, work). It writes the map into each repo's `CLAUDE.md` / `AGENTS.md` inside a marked block, symlinks the skills each repo should have, and lets the agent read the related repos without a permission prompt for every file. A scope (`personal`, `acme`, `acme-ml`) decides which repos see which content, and nothing ever crosses into a repo outside its scope.

## Known repos (acme)
- billing-api (billing, invoices) — Invoicing and payment orchestration; OpenAPI in api/openapi.yaml · ~/work/acme/billing-api
- events-pipeline (events, pipeline) — Kafka c