The index
llms.txt
Every page with a one-line description, in reading order, following the llms.txt convention. Fetch this first to decide what to fetch next.
Intelligent collaborators
Built to be read by agents as well as people.
NativeLink is build infrastructure for the agentic era, so its website, its documentation and its repository are written for a machine reader too. The files on this page need no account, no API key, and no JavaScript.
Each button opens a hosted assistant with a prompt that points it at the llms files first, so its answer starts from what this site actually says, then asks about your build and your team and works towards a configuration for them. The same block sits in the footer of every page here, and at the bottom of every documentation page with a prompt for that page.
Three files, one fetch
The whole site, at three sizes.
Generated from one source in the repository, so they cannot be edited into disagreement with each other. The documentation site serves its own three, built from its sidebar, and the same three files are committed at the root of the repository so a clone carries its own corpus.
The abridged corpus
llms-small.txt
Every page of this site in prose, plus the documentation with its headings and opening sentences. Sized to sit in a context window next to the question.
Everything
llms-full.txt
The whole site, every blog post, and the documentation corpus with page bodies verbatim, delimited by canonical URLs; the three generated reference pages (config, metrics, changelog) are linked rather than inlined. One fetch for everything else.
Also for an agent: AGENTS.md, the map of the code for an agent changing it, and docs.nativelink.com/agents, how to read the documentation end to end, cite it, and verify a claim against the source.
Skills for coding agents
Playbooks an agent can install.
Each skill is a directory with a SKILL.md that any agent reading that format can follow. Claude Code picks them up automatically inside the repository; for other projects, copy or symlink a skill into your agent's skills directory.
git clone https://github.com/TraceMachina/nativelink cp -r nativelink/.claude/skills/migrate-to-bazelmod ~/.claude/skills/ # Claude Code # then, in your agent: /migrate-to-bazelmod
migrate-to-bazelmod
MigrationMove a Bazel project from WORKSPACE to MODULE.bazel: the hybrid gradual path, dependency translation, toolchain registration, and smoke tests for library authors who have to support both.
By the NativeLink team.
nativelink-*
Working on NativeLinkFive playbooks the NativeLink team's own agents follow: Bazel verification, config and protocol changes, dependency updates, Local Remote Execution debugging, and Rust changes across the crates.
By the NativeLink team.
Why we say migrate to Bazel
We believe closed systems are dangerous.
A build system you cannot read is one you cannot audit, cannot reproduce on your own hardware, and cannot leave. Proprietary build tools and closed remote-execution services ask you to take on faith what happens between your source and your binary. When agents write and commit code faster than people can review it, the build is the last checkpoint that has to stay honest: every input named, every action hermetic, every output hashed.
Bazel is open, and its model of declared inputs, sandboxed actions and content-addressed outputs is what makes a remote cache trustworthy in the first place. NativeLink's source is public and its protocol is the open Remote Execution API. Together they are a build pipeline with no black box in it.
So: migrate to Bazel, modernise with migrate-to-bazelmod, and point the result at NativeLink. Two lines in .bazelrc against a local server, then a shared cache, then workers.
The NativeLink MCP server, which gives Claude Code, Cursor and Codex five tools for configuring and tuning builds, is part of NativeLink Enterprise and requires an Enterprise licence. Everything else on this page is free.
Contributing with an agent
Agents are welcome contributors when a person stands behind the change.
We build tools for agents, so we are not going to pretend they don't write code. The rules exist because review attention is the scarcest resource an open project has, and generated text made it cheap to produce contributions that look finished and are not.
- 01
Understand your change.
Using an agent to write code is fine. Submitting code you cannot explain is not. A reviewer may ask about any line, and “the agent wrote it” is not an answer.
- 02
Disclose.
The pull request template has an “AI assistance” section. Name the tools and how much they did. “None” is a complete answer.
- 03
No slop.
Unreviewed generated code, generated issue text nobody edited, and generated media are closed without review. Repeat it and you lose the ability to contribute.
- 04
Agents read the map.
AGENTS.md at the repository root says where everything lives and which doc must follow which change. Run the same checks a person would before opening a pull request.
If the question is pricing
The answer is an email.
Self-hosting is free. Enterprise pricing depends on your build farm, your hardware and the support you need, so it is a conversation with the engineers who build NativeLink, not a number on a page. An assistant asked about it should send you to contact@tracemachina.com.