Automation & Execution

Flows, scripts, sandboxes and data pipelines. Captured from kis --help, so this matches the binary rather than describing it.

`kis flow`

Run automation workflows from the command line (alias: automate)

kis flow [flags]

Flag	Purpose
`-d, --dryrun`	Is the execution just a dry run
`-e, --env string`	Environment yaml file path
`-f, --flow string`	Flow yaml file path
`-n, --name string`	Environment name (default “default”)
`-s, --start string`	Flow start task
`-t, --tasks strings`	List of tasks to be executed
`-v, --vars stringToString`	Variables (default [])
`-w, --workers int`	Number of workers (default 1)

`kis automate`

Run automation workflows from the command line (alias: automate)

kis flow [flags]

Flag	Purpose
`-d, --dryrun`	Is the execution just a dry run
`-e, --env string`	Environment yaml file path
`-f, --flow string`	Flow yaml file path
`-n, --name string`	Environment name (default “default”)
`-s, --start string`	Flow start task
`-t, --tasks strings`	List of tasks to be executed
`-v, --vars stringToString`	Variables (default [])
`-w, --workers int`	Number of workers (default 1)

`kis script`

Execute scripts directly from the CLI — same engine and calling convention as the flow YAML script: task. A script that runs in a flow runs here too.

Examples: kis script run hello.js kis script run greet.js anand 7 # positional -> main(“anand”, 7) kis script run x.js —vars name=anand # bare-global ‘name’ kis script run x.js —func handler 3 4 # call exported handler(3, 4) kis script run plugin.wasm kis script bench hello.js —iterations 1000

kis script [command]

Subcommand	Purpose
`bench`	Benchmark plugin execution performance
`compile`	Test compilation for different runtimes
`rules`	Batch-process JSON files through a Maya plugin
`run`	Execute a plugin file directly
`validate`	Validate plugin syntax
`version`	Show script-engine version information

`kis script bench`

Benchmark plugin execution performance

kis script bench <plugin-file> [flags]

Flag	Purpose
`-f, --func string`	Function to call (default “main”)
`-i, --input string`	Input JSON (inline or file path) (default ”{}“)
`-n, --iterations int`	Number of iterations (default 1000)
`-r, --runtime string`	Runtime to use (e.g., v8, goja for JavaScript)
`-w, --warmup int`	Warmup iterations (default 100)

`kis script compile`

Test compilation for different runtimes

kis script compile <plugin-file> [flags]

Flag	Purpose
`-r, --runtime string`	Runtime to test (auto-detect by default)

`kis script rules`

Process all JSON files in a directory through a Maya plugin.

Reads JSON files matching a glob pattern, merges in facts and variables, optionally loads bbox OCR documents, executes the plugin for each file, and optionally writes results back (in-place or to an output directory).

Examples: kis script rules transform.js —input ./data —update kis script rules —input ./docs —bbox invoice=ocr.json —update extract.lua kis script rules —input ./in —output ./out —pattern “*.json” process.js kis script rules —with-bbox —update classify.js —input ./pages

kis script rules <plugin-file> [flags]

Flag	Purpose
`-b, --bbox stringArray`	Bbox OCR JSON files ([name=]path)
`-e, --env string`	Environment YAML file
`-f, --func string`	Function to call in the plugin (default “main”)
`-i, --input string`	Input directory with JSON files (default ”.”)
`-k, --key string`	Nest results under this key
`-n, --name string`	Environment name (default “default”)
`-o, --output string`	Output directory (default: same as input)
`-p, --pattern string`	Glob pattern for files to process (default “*.json”)
`-r, --runtime string`	Runtime override (e.g., v8, goja)
`-t, --timeout int`	Execution timeout in milliseconds (default 5000)
`-v, --vars stringArray`	Variables as key=value pairs
`-w, --workers int`	Number of parallel workers (default 1)

`kis script run`

Execute a plugin file directly without requiring pointcut definitions.

Supported languages are auto-detected by file extension: .js JavaScript (Goja) .lua Lua .go Go (Yaegi interpreter) .star Starlark .cel CEL .expr expr .wasm WebAssembly (wazero)

Two channels deliver data into the script:

Positional args (after the file) -> function arguments, variadic. —args (repeatable) -> also function arguments, appended to the positional ones. —vars k=v / —env file.yaml -> bare globals (kis ambient scope) — same as flow YAML’s vars: block.

Each arg value is JSON-parsed best-effort; string fallback otherwise.

Examples:

kis script run greet.js anand 7 -> main(“anand”, 7) kis script run process.js ‘[1,2,3]’ ’{“k”:1}’ -> main([1,2,3], {k:1}) kis script run hello.js -> main() no args kis script run x.js —args anand —args 7 -> same as positional ‘anand 7’ kis script run x.js —vars name=anand -> main() with bare-global ‘name’

kis script run <plugin-file> [args...] [flags]

Flag	Purpose
`-a, --args stringArray`	Function argument (repeatable). Each occurrence is one positional arg; JSON-parsed best-effort, falls back to string. Combines with positional args after the file.
`-d, --debug`	Debug output
`-e, --env string`	Environment yaml file path
`-f, --func string`	Function to call (default “main”)
`-n, --name string`	Environment name (default “default”)
`-r, --runtime string`	Runtime to use (e.g., v8, goja for JavaScript)
`-t, --timeout int`	Execution timeout in milliseconds (default 5000)
`-v, --vars stringToString`	Variables (default [])

`kis script validate`

Validate plugin syntax and check if it compiles correctly.

kis script validate <plugin-file> [flags]

Flag	Purpose
`-r, --runtime string`	Runtime to validate against (auto-detect by default)

`kis script version`

Show script-engine version information

kis script version [flags]

`kis sandbox`

Drive the isolation-and-clone engine directly.

Backends available on this host are wired at build time: process and wasm everywhere, seatbelt and apple-container on macOS, oci/bubblewrap/landlock/ firecracker on Linux. Tier selection picks the most-restrictive available backend unless —backend pins one.

kis sandbox [command]

Subcommand	Purpose
`backends`	List the sandbox backends wired into this build and their capabilities
`create`	Create a long-lived session and print its id
`exec`	Run a command in a long-lived session (created on first use)
`run`	Clone a base and run one command in a confined workspace
`session`	Manage long-lived sandbox sessions (create, list, destroy)
`shell`	Open a durable shell in a confined workspace and run lines from stdin

`kis sandbox backends`

List the sandbox backends wired into this build and their capabilities

kis sandbox backends [flags]

`kis sandbox create`

Create a persistent sandbox. An id may be given; otherwise one is generated. The runtime stays alive until session destroy.

kis sandbox session create —tier microvm —base-kind oci_image —base ubuntu:24.04 kis sandbox session create mywork —tier container —base /tmp/rootfs

kis sandbox create [id] [flags]

`kis sandbox exec`

Run one command against a persistent session. If the session does not exist, it is created from the clone flags; otherwise the existing runtime is reused (files and background processes persist). The runtime is left alive — end it with kis sandbox session destroy <id>.

kis sandbox exec —session mywork —tier microvm —base-kind oci_image
—base ubuntu:24.04 — sh -c ‘echo hi > /work; cat /work’

kis sandbox exec --session <id> [flags] -- command [args...]

`kis sandbox run`

Materialize a copy-on-write workspace at the chosen tier and run one command in it, streaming stdout/stderr and exiting with the command’s code.

Examples: kis sandbox run — /bin/echo hi # empty workspace, host tier kis sandbox run —base . — ls -la # clone the current directory kis sandbox run —tier wasm —base prog.wasm # run a WASI module kis sandbox run —tier process —allow-process-tier — env

kis sandbox run [flags] -- command [args...]

`kis sandbox session`

A session is a persistent sandbox whose runtime stays alive across invocations. Create one, then run commands against it with kis sandbox exec --session <id> or kis sandbox shell --session <id>. Sessions need a container or microVM tier (a runtime that can outlive the CLI).

Pass —server to any session command to drive a workspace.svc instance instead of a local runtime — the sandbox then lives on the service’s host.

kis sandbox session [command]

Subcommand	Purpose
`create`	Create a long-lived session and print its id
`destroy`	Destroy a session and its runtime
`list`	List sessions

`kis sandbox shell`

Materialize a workspace and open a persistent shell whose cwd and env survive across commands. Each line read from stdin is run in the session; output is printed, then a [exit N] line. Ends on EOF (Ctrl-D) or Ctrl-C.

Example: echo -e ‘cd /tmp\npwd’ | kis sandbox shell —base .

kis sandbox shell [flags]

`kis datapipes`

Execute data pipeline workflows from the command line.

If —env is not given, ./env.yaml is auto-loaded when present. If —dotenv is not given, ./.env is auto-loaded when present. Precedence (highest to lowest): —vars > env.yaml > .env > flow file vars.

kis datapipes [flags]

Flag	Purpose
`-e, --env string`	Environment YAML file path (auto-loads ./env.yaml if not set)
`-f, --flow string`	Flow YAML file path
`-n, --name string`	Environment name (default “default”)
`-s, --start string`	Flow start task
`-t, --tenantkey string`	Custom tenant key
`-v, --vars stringToString`	Variables (default [])
`-w, --workers int`	Number of workers to start for execution (default 1)