Variables & precedence

Variables are named text values that templates read as {{vars.NAME}}. They keep project-specific details (test commands, target labels, reviewers, feature flags) out of prompts, so one pipeline can be reused and tuned per run.

Sources

Source	Where you set it	Names
Project commands	Project → Commands (Setup, Start, Test, Build, Lint)	setupCommand, startCommand, testCommand, buildCommand, lintCommand
Project variables	Project → Variables	any
Pipeline variables	Pipeline settings → Variables	any
Run overrides	The Start a run dialog: one vars.NAME field per variable	the variables the pipeline already has

Precedence

Later sources override earlier ones for the same name:

project commands  <  project variables  <  pipeline variables  <  run overrides

So a pipeline variable named testCommand beats the project’s Test command, and a value typed into Start a run beats both.

In the pipeline editor, a pipeline in a project shows the inherited values under From project name; any the pipeline overrides are struck through (“Overridden by this pipeline”).

Per-run overrides

The Start a run dialog lists every variable the run will see (project and pipeline, merged), each with its default shown as the placeholder and hint. Leave a field empty to keep the default; empty fields are not sent, so you can’t override a variable to an empty string from the dialog.

Runs started by triggers use the defaults; triggers don’t set variables.

Overrides are stored with the run, and a Retry keeps them.

Using variables

Follow the team's conventions in {{vars.styleGuide | default:"CONTRIBUTING.md"}}.

In shell steps, variables are quoted like any other value. Use | raw for variables that hold commands:

{{vars.setupCommand | raw}} && {{vars.testCommand | raw}}

As a feature flag with Run only if (runIf):

{{vars.deploy}}

A variable that doesn’t exist renders as empty, so runIf: {{vars.deploy}} skips the step unless deploy is set to something truthy (not '', false, 0 or no).

Naming

Variable names are free-form keys. Stick to letters, digits and _ so they work as template paths ({{vars.my_var}}); a name containing . can’t be referenced, because . separates path segments.

Variables vs. environment variables

Variables are template values; they’re substituted into text before a step runs. Environment variables are set on the step’s process. They have their own sources and precedence (lowest first):

Jimothy's base env (your login-shell PATH, CI=1, NO_COLOR=1, …)
  < Settings → Environment variables
  < project Environment
  < step Environment
  < FACTORY_* variables (always set by Jimothy, can't be overridden)

For agent steps, the harness’s own env (configured on the Harnesses page) is applied on top for CLI harnesses. See Environment variables for the full list of FACTORY_* variables.

Template variables are not exported to the environment automatically. To pass one to a script, put it in the command (MY_FLAG={{vars.flag}} ./script.sh) or in the step’s Environment (environment values are literal text, not templates).