rtb CLI reference¶

rtb is the scaffolder binary shipped by the rtb-cli-bin crate. It is itself built on the framework, so its command list is the three scaffolder verbs plus every framework built-in.

Install it on its own — the umbrella rust-tool-base crate does not depend on it, so a tool that builds on RTB never pulls the scaffolder's templates or its minijinja / inquire dependencies into its own binary:

$ cargo install rtb-cli-bin

The whole command tree¶

rtb
├── generate      scaffolder — see reference/cli/generate.md
│   ├── project
│   ├── command      ├── protect
│   │                └── unprotect
│   ├── flag
│   ├── setting
│   └── docs
├── remove        scaffolder — see reference/cli/remove.md
│   ├── command
│   ├── flag
│   └── setting
├── regenerate    scaffolder — see reference/cli/regenerate.md
│   ├── manifest
│   └── project
├── config        framework — see reference/cli/built-in-commands.md
├── credentials   framework
├── docs          framework
├── doctor        framework
├── mcp           framework
├── telemetry     framework
├── update        framework
└── version       framework

generate, remove and regenerate are the scaffolder's own verbs. Everything else is inherited from rtb-cli, which is what a tool scaffolded with the cli preset also inherits — see built-in commands.

Global options¶

--output is declared once on the root parser and may appear anywhere on the line, before or after the subcommand, as --output json or --output=json. Only the credentials leaves that emit tabular data consume it. version and doctor advertise it in their own --help but always print text; see what RTB does not do.

An unrecognised value is not an error: --output yaml silently resolves to text. So does a bare trailing --output with no value.

There is no rtb --version¶

The version flag is a subcommand, not a root flag:

$ rtb version
rtb 0.9.0
  target: x86_64-linux

rtb --version exits 1 with command not found: --version, because the root parser treats the first token as a subcommand name. Tools scaffolded from the minimal preset behave the other way round — they ship a root --version flag and no version subcommand.

Exit codes¶

There are no finer-grained codes. A caller that needs to distinguish failure kinds should match the diagnostic code printed with the error (rtb::command_not_found, rtb::scaffolder::validate::invalid_input, rtb::doctor::failed, …) rather than the exit status.

Diagnostics¶

Errors render through miette. A rejected input names the field and the rule it broke, and usually carries a help: line with the fix:

$ rtb generate setting my_setting
  x invalid setting name: flag_name: must match ^[a-z][a-z0-9-]{0,63}$ — kebab-case, ASCII, letter first

The patterns behind those messages are listed in validation rules.

Commands that need a scaffolded project¶

generate command, generate flag, generate setting, generate docs, every remove kind, and both regenerate kinds read .rtb/manifest.yaml from the project root and fail if it is absent. Only generate project can run outside a scaffolded tree.

The project root is the current directory unless the command takes -p, --path <PATH>. Note that -p is available on generate setting, generate docs, regenerate manifest and regenerate project, but not on generate command, generate flag or any remove kind — those always operate on the current directory.