Kin
About
The system of record for AI-written software. A persistent graph of entities, relationships, changes, and provenance, so humans and AI agents see what a change touches before it merges. Beside Git today.
Details
- Author
- Troy Fortin, Jr. (Firelock, LLC)
- GitHub stars
- 45
- Downloads
- 1,595
- Categories
- Developer Tools, Search, Knowledge Base
Jump to
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
KinCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
{
"mcpServers": {
"kin": {
"command": "npx",
"args": [
"-y",
"@kinlab/kin-mcp"
]
}
}
}
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"kin": {
"kin": {
"command": "npx",
"args": [
"-y",
"@kinlab/kin-mcp"
]
}
}
}
}McpServers
{
"kin": {
"command": "npx",
"args": [
"-y",
"@kinlab/kin-mcp"
]
}
}AI agents can write a change faster than a team can establish what it touches, whether it reverses an earlier fix, and how far its consequences reach. Git records files and line history. Kin records the software itself as a graph of entities, relations, changes, and provenance, then gives humans and agents one semantic authority to query and review. What a change touches shows up before it merges, and agents work from exact context instead of re-reading the repository.
Kin is the semantic system of record for AI-written software. It is a public alpha, usable today as a local CLI, daemon, MCP server, review surface, and graph-backed filesystem projection. It is pre-1.0, so expect rough edges and breaking changes. See thelatest stable releaseand thecurrent limitationsbefore adopting it in a critical workflow.
A one-line signature change in ripgrep looks harmless in the diff. Askkin impactabout it, before any compiler runs, and it names what the edit reaches. The callers of the changed signature come first, then everything those callers pull in behind them.
Recorded against a prepared graph at ripgrep commite89fff89ac9af12e8d4ce9d5fd07beb408ca730f. A one-line signature edit, and Kin surfaces the entities it affects before a compiler runs. The graph was built beforehand. No compiler ran. Exact commands:kinlab.ai/proof. The raw run directory is not public yet, so this is a recipe you can re-run, not a trace you can audit.
Kin surfaces what the change touches. Whether the change is correct stays with your compiler, tests, and review. The graph is built beforehand bykin init, and building it is the expensive part; after that, impact questions are answered from graph truth, not from re-reading the tree.
Kin is one system with a few clear public surfaces:
Kin is the semantic system of record for AI-written software, and everything in the map below either reaches that authority or supports it. Humans and AI agents come in through the CLI, the bundled MCP server, or the VS Code extension. All three ask the same daemon, and the daemon answers from graph authority rather than by re-reading the tree.kin-vfsprojects that same graph back through ordinary filesystem calls, so editors, compilers, and build systems keep seeing files. Git sits beside the graph as an import and export boundary rather than as an answer path, and KinLab is the hosted layer over the same authority.
flowchart TD people["Humans and AI agents"] subgraph surfaces["Access surfaces"] cli["kin CLI"] mcp["Kin MCP server"] editor["kin-editor for VS Code"] end daemon["kin daemon"] authority["Graph authority<br/>entities, relations, changes, provenance"] db["kin-db<br/>graph storage, snapshots,<br/>index, text and vector search"] prims["kin-model, kin-blobs, kin-search,<br/>kin-vector, kin-infer, kin-lsp"] vfs["kin-vfs<br/>transparent file projection"] tools["Editors, compilers, build systems"] git["Git<br/>import and export boundary"] kinlab["KinLab<br/>hosted collaboration and control plane"] people --> cli people --> mcp people --> editor cli --> daemon mcp --> daemon editor --> daemon daemon --> authority authority --> db db --> prims authority <-->|"kin init imports, kin git export"| git authority -->|"publish and sync"| kinlab authority --> vfs vfs --> tools
Underneath those surfaces are the layers the system is built from:
These are implementation layers of one system, not separate products a new user needs to assemble. None of them is installed separately.
The core of Kin is open source under Apache-2.0:kin,kin-db,kin-vfs, andkin-editor, plus the supporting libraries kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp, and kin-actions.
The same boundary applies to how benchmark work is shared. Thebenchmark specification and a standalone, dependency-free bundle verifierare public, so a claim can be checked without access to the system that produced it. The runner and proof infrastructure that produce sealed evidence bundles (the orchestration, the pinned-release proof gate, and the hosted measurement environment) remain private for now. The spec and verifier open first; the runner can open later.
curl -fsSL https://get.kinlab.dev/install | sh exec "$SHELL" -l kin setup --intent agent
To remove only setup-managed integrations, runkin setup uninstall. For the default managed root (~/.kin),kin setup uninstall --allalso stops all Kin daemons, removes exact legacy installer PATH blocks, and recursively deletes the managed install (--dry-runpreviews it). A customKIN_HOMEis never removed recursively: first run the ledger-scoped uninstall, then review and remove that directory explicitly. Modified setup-owned slices block full removal unless you add--force, so uninstall never silently overwrites a user's edited client or shell configuration. On Windows, the CLI schedules its locked install directory for deletion immediately after the running process exits. Windows intentionally retains one inert, current-user-only sibling authority sidecar; keeping that lock identity stable prevents a crash or concurrent future install from creating two independent mutation authorities. The CLI and JSON result disclose this retained coordination metadata rather than claiming zero residual bytes.
For manual installation, each archive and its.sha256file is published underhttps://github.com/firelock-ai/kin/releases/latest/download/. The moving asset names arekin-macos-aarch64,kin-macos-x86_64,kin-linux-aarch64,kin-linux-x86_64, andkin-windows-x86_64; use the.tar.gzsuffix for the macOS and Linux archives and the.zipsuffix for Windows, as shown on the latest release page. The Windows zip is also what the PowerShell installer and the npm launcher fetch.
The npm entry point resolves the same public release channel:
A global install needs a writable npm prefix. Where the prefix is root-owned and you are not root, npm refuses withEACCES: permission denied, mkdir '/usr/local/lib/node_modules/@kinlab'before Kin runs at all, which is the usual case inside a container whose default user is not root. Either use the zero-install path,npx -y @kinlab/kin setup --intent agent --no-interactive, or move the prefix somewhere you own and put it on yourPATH:
npm config set prefix ~/.npm-global export PATH="$HOME/.npm-global/bin:$PATH" # add this to your shell profile too npm install -g @kinlab/kin@latest
A user prefix is on your interactive shell'sPATHand nowhere else. Scripts, CI steps,docker exec, and agent clients do not inherit it, so give those the absolute path to the binary rather than a barekin. See[Works with your agentfor the registration shape.
A Homebrew tap tracks the same release channel:
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
