Skip to main content
llmwiki workflow runs workflows declared by the active profile. Workflows are configuration, not code: each stage declares what entity types it reads, what it may write, optional artifact outputs, and optional gates.

​
Discover workflows

workflow list prints every workflow id declared by the active profile. workflow show prints the stage list, reads, writes, gates, projection file, and declared actions.

​
Start and inspect a run

Workflow runs are durable records under .llmwiki/. workflow status is read-only and exits non-zero when a run is blocked by profile changes, unavailable state, or other integrity problems.

​
Advance a run

Advancing moves the run to the next stage when its current stage is satisfied. A stage with an unapplied write, unsatisfied gate, or blocked output stays parked until the required action is taken.

​
Submit stage output

Supported output kinds: Every output is checked against the active profile. Page outputs must satisfy field contracts and lifecycle rules. Relation outputs must match declared endpoint types. Artifact outputs must match the stage’s artifactWrites list.

​
Gates and trusted writes

Profiles can declare trust:, human:, and agent: gates.
  • A trust: gate requires an out-of-workspace operator grant before a clean stage write auto-applies live.
  • The grant is LLMWIKI_TRUSTED_WRITE=<profileId> or LLMWIKI_TRUSTED_WRITE=*.
  • A parked output prints whether the grant can help. Planner denials and quarantine decisions are not overridden by the grant.
  • A human: gate is satisfied only through the interactive confirmation path. --actor human is rejected.

​
Workflow actions

Profiles can expose named actions as shortcuts over workflow operations.
Action authority is composed from the profile’s requested permission, local configuration, and the surface hard cap. CLI and SDK can reach trusted-write when granted. MCP and viewer surfaces are capped at staged-write.

​
Adapt, project, and finish runs

workflow project writes a derived markdown projection only when the workflow declares projectionFile. It does not change the run state.

​
When to use the local engine

llmwiki workflow is the lightweight tier: each invocation runs locally on one machine, with mutations serialized by the project lock and no orchestration service required. Run records persist under .llmwiki/ between invocations, including while a run waits for human approval. The whole run does not need to finish in one process or terminal session. It remains supported on its existing experimental terms. It is not a durable orchestration platform. Reach for your own coordinator, built on the standard SDK, when you need:
  • automatic work dispatch and worker recovery after process failure
  • distributed execution or managed multi-user approval routing
  • built-in scheduling or event-triggered execution of repeated runs
  • coordination across several projects or services
Persisted local state is not a promise of automatic replay or retry of an interrupted action. Inspect the recorded state before taking recovery actions. That coordinator calls compiler services for retained data and authorized effects; it does not gain approval or trusted-write authority by existing. See External orchestration and operation authority.