Reference

CLI reference

The stele command surface follows one consistent grammar: stele <object> <verb>. Learn the verbs once and they mean the same thing on every object. This page is the shape of the surface; stele --help and stele <object> --help give the exhaustive, always-current detail.

The verb grammar

Every object that supports an operation uses the same word for it: get, never show or view; list, never ls; create, never add.

Verb	What it does
`get <id>`	Fetch one object, with its full body.
`list`	Enumerate objects, filtered and paginated; cards only, no bodies.
`create`	Make one.
`update <id>`	Edit fields on one.
`search <query>` · `grep <pattern>`	Find, scoped to the object when run under it (e.g. `task search`).

terminal

$stele task get TASK-12

$stele knowledge list --component auth

$stele task search "pagination"

The objects

Each node type and structure is a top-level object with the verbs above, plus actions specific to it.

Object	Read / write	Dedicated actions
`task`	get · list · create · update	`claim` · `complete` · `release` · `reopen` · `cancel` · `subtasks`
`objective`	get · list · create · update	`achieve` · `add-milestone` · `milestones` · `retire`
`knowledge`	get · list · create · update	`review` · `dedupe`
`document`	get · list · create · update	`grep` (body search)
`component`	get · list · create · update	`tree`
`workspace`	get · list · create · update	`activate` · `merge` · `cherry-pick`
`node`	get (any id) · update	version history · restore · the low-level, type-agnostic escape hatch

Cross-cutting verbs work across types: search, grep, recall, context (build or trace), stats, and doctor.

Account & project

Setup and administration live under their own commands.

Command	What it does
`stele account login`	Sign in (and `logout`, account info).
`stele project`	Create, list, and bind the project for this directory.
`stele install`	Set Stele up for the coding agents you choose (and `uninstall`).
`stele web`	Open the dashboard, backed by a local server when you want it.
`stele status` · `stele doctor`	See where things stand; audit the graph's health, and check whether context injection is running slow or quietly falling back.
`stele update`	Upgrade the CLI and refresh the plugin for the agents you set up.

Loop verification and evidenced attempts

stele loop verify is the local integrity gate used by Stele Operator. Given a task and two Git refs, it computes the changed files from the local repository and proves that none overlap the task's declared check_paths. The worker does not get to provide that changed-file list.

terminal

$stele loop verify --task TASK-12 --base main --branch worktree-agent-12

Exit 0: the declared oracle paths are untouched.
Exit 1: the diff modified a protected check path.
Exit 2: verification is unknown. For example, the task lacks check_paths, a ref is invalid, or local Git is unavailable. Operator stops; it never rounds unknown up to green.

The same capability is available over MCP

A local Stele MCP server can run the same verifier through the loop inspect action or the flat verify_loop tool. Hosted MCP cannot inspect your local Git repository, so it fails closed and directs Operator to a local MCP server or this CLI command.

stele loop attempt adds execution evidence to that integrity gate. It resolves the branch's registered worktree, runs the declared check with a fresh STELE_LOOP_NONCE, and records the result on the task. The check must emit one STELE_LOOP_EVIDENCE={...} JSON line with matching nonce and non-zero execution counts. Missing, replayed, or malformed evidence fails closed.

terminal

$stele loop attempt --task TASK-12 --base main --branch worktree-agent-12

$stele loop finalize --task TASK-12 --reviewer approved --reviewer-summary "Review passed." --operator approved --operator-summary "Intent passed."

Attempts stop after five runs or after the same failure signature occurs twice in a row. loop finalize stores the deterministic, reviewer, and operator verdicts separately; final approval requires all three. Stele does not enforce model-provider spend limits.

Output conventions

Browse, don't dump. get <id> shows the full object because you asked for exactly one; list, search, and grep return compact cards, never full bodies.
--json everywhere. Every read can emit JSON for scripting.
Next-action hints. Human output suggests the likely next step (get a task → how to claim it); --no-hints silences them.
Destructive verbs ask first. Anything that removes or merges is dry-run by default and needs --confirm to proceed.

The CLI is self-documenting

You don't need to memorize this. stele --help prints the full command tree, every subcommand has its own --help, and a mistyped command suggests the right one.

Slash commands The model behind the objects