Skip to main content
rbs works in a repository that has never heard of it. In a directory with no WORKSPACE.rbs, the everyday commands detect the project type themselves and run against a synthesized workspace — and rbs adopt materializes that same config as real files when you want to start editing it.

​
Zero config: just run it

Detection fingerprints the project (a go.mod, a package.json, a requirements.txt, …) and generates config under .rbs/zero-config/ — rbs-owned state, never your checkout; rbs even adds .rbs/ to .git/info/exclude so git status stays clean. Bare rbs run runs the detected default target. Run the commands from a subdirectory and rbs detects at the enclosing git root. rbs query and rbs graph show the synthesized targets too, and agents running on the branch server see the same graph. Opening a non-rbs repo in the ReasonOS editor shows the same thing as a slim banner: “Zero-config: detected go — build, run and test already work.” Its Adopt button writes the exact config zero-config has been executing into the repo — the same files rbs adopt produces.

​
Adopt: materialize the config

rbs adopt writes the WORKSPACE.rbs and BUILD.rbs a person familiar with rbs would have written by hand — toolchain pinned from your version files, dependencies declared from your manifest, a runnable binary target, test targets when tests exist. It is byte-identical to what zero-config mode was executing, so nothing changes behavior — the config just becomes yours to edit.
The generated files are yours: they carry a “review and edit” header, and rbs adopt never rewrites them afterwards. There is no hidden configuration layer — what adopt generates is exactly the config you edit as the project grows.

​
Command forms

Adopt refuses a directory that already contains a WORKSPACE.rbs, and refuses to nest a workspace inside an existing one — add a BUILD.rbs package to the enclosing workspace instead.

​
What gets detected

​
Container image out of the box

For Go projects the generated config includes a container image: a cross-compiled linux binary on a minimal scratch base. Building it needs no Docker daemon — rbs assembles the image itself:
The generated file explains how to switch the base image (for CA certificates or a shell) and how to upgrade to a multi-arch image index. Node and Python images aren’t generated yet — they need a linux-native runtime inside the image; the converter tells you so during adopt. When a repo matches several converters, ranking follows language priority first (a Go service with a docs package.json adopts as Go), then detection confidence. Anything a converter can’t translate — an unpinned requirement, a file: dependency, TypeScript builds — is reported as a note during adopt, never silently dropped.

​
Extending detection

Converters are Starlark, not compiled-in logic. Rule authors register one with native.define_project_converter(name, detect, convert, priority), and detection is extensible without rebuilding rbs — point at an external converter pack:
A pack is a git repo (fetched pinned to the ref, same as rbs ext) or a local directory whose convert.rbs modules register converters. A pack converter that re-declares an embedded name overrides it. See Custom rules for the rule-authoring surface.