---
title: "Workflows in the CLI"
canonical: https://trickest.com/docs/developer-tools/cli/workflows
description: "Create, inspect, copy, move, and bulk-edit Trickest workflows from the CLI, including atomic YAML apply and patch."
---

# Workflows in the CLI

<Info>
**Platform concepts:** what workflows are and how they work in the product:
[Workflows](/docs/key-concepts/workflows). This page is the **`trickest workflow`**
command reference only.
</Info>

A **workflow** is a DAG of nodes (tools, scripts, modules, primitives) that runs on
the Trickest fleet. The `workflow` command family manages workflows themselves;
their internal structure is edited with [`node`](/docs/developer-tools/cli/nodes)
and analyzed with [`graph`](/docs/developer-tools/cli/graph).

<Note>
`workflow ls` lists workflows in your **active space** by default. Most other
workflow subcommands take an explicit `<name-or-id>`. The structural commands
(`node`, `graph`, `save`, `workflow summary/apply/patch`) operate on your **active
workflow** context, see [Configuration & Context](/docs/developer-tools/cli/configuration).
</Note>

## Command summary

| Subcommand | Description |
|---|---|
| `workflow ls` | List workflows in the current space (`--all` for every space) |
| `workflow info\|get [name-or-id]` | Get workflow details |
| `workflow create <name>` | Create a workflow in the current space |
| `workflow use <name-or-id>` | Set the active workflow context |
| `workflow rename <name-or-id> <new-name>` | Rename |
| `workflow update <name-or-id>` | Update metadata |
| `workflow cp <name-or-id> <new-name>` | Copy |
| `workflow mv <name-or-id> [new-name]` | Move to another space |
| `workflow rm <name-or-id>` | Delete |
| `workflow summary` | Nodes, connections, ASCII DAG, issues (active workflow) |
| `workflow apply` | Create nodes + connections atomically from YAML |
| `workflow patch` | Apply targeted updates to existing nodes from YAML |

## Listing & inspecting

### `workflow ls`

```bash
trickest workflow ls
```
```json
[{"name":"DAST v2","id":"7b4a4059-…","description":"","created":"2026-05-21T14:48:03Z","modified":"2026-05-21T14:48:06Z"}]
```

| Flag | Description |
|---|---|
| `--space <name-or-id>` | List workflows in a specific space |
| `--all` | List workflows across **all** spaces (not just the active one) |
| `--filter <query>` | Filter by name substring |
| `--fields <fields>` | Comma-separated fields (e.g. `name,id,status`) |

```bash
trickest workflow ls --all
trickest workflow ls --filter dast --fields name,id
```

### `workflow info`

Get one workflow (`get` is an alias). Without a name or ID, it reads the active
workflow. Pass an ID to inspect a specific workflow:

```bash
trickest workflow info "DAST v2"
trickest workflow get <workflow-id>
```
```json
{"name":"DAST v2","id":"7b4a4059-…","description":"","created":"2026-05-21T14:48:03Z","modified":"2026-05-21T14:48:06Z","is_template":false}
```

<Tip>
`workflow get` also returns a `schedule_info` field, that's how you read a
workflow's schedule (see [Schedules](/docs/developer-tools/cli/schedules)).
</Tip>

## Creating & organizing

### `workflow create`

```bash
trickest workflow create "Discovery Pipeline" --description "Subdomain → probe → scan"
```

| Flag | Description |
|---|---|
| `--description <desc>` | Workflow description |
| `--project <project>` | Project ID to place the workflow in |
| `--space <space>` | Target space (overrides active context) |

### `workflow cp` / `mv` / `rename`

```bash
trickest workflow cp "DAST v2" "DAST v2 (copy)"            # copy in place
trickest workflow cp "DAST v2" "DAST clone" --space "Red Team"   # copy to another space
trickest workflow mv "DAST v2" --space "Red Team"          # move, keep name
trickest workflow mv "DAST v2" "DAST renamed" --space "Red Team" # move + rename
trickest workflow rename "DAST v2" "DAST v3"
```

### `workflow rm`

```bash
trickest workflow rm "DAST v3" --force
```

## Setting the active workflow

Workflow-scoped commands act on whichever workflow you've made active:

```bash
trickest workflow use <workflow-id>
# Active workflow set to: DAST v2

trickest switch /spaces/Solutions/workflows/"DAST v2"   # sets space + workflow
```

Node edits, connections, `workflow apply`, and `workflow patch` already save a new
version on the server. There is no local staging area that needs a final commit.
`save` reads the latest graph and saves another version of it; it does not execute
the workflow or publish it to the Library:

```bash
trickest save
```

## Inspecting structure: `workflow summary`

A quick, human-readable overview of the active workflow, node count, connections,
an ASCII DAG, and any structural issues:

```bash
trickest workflow summary
```

For machine-readable structure, use [`node ls`](/docs/developer-tools/cli/nodes) and
[`graph analyze`](/docs/developer-tools/cli/graph).

## Bulk authoring: `apply` and `patch`

These two commands let you build and modify workflows declaratively from YAML:
ideal for agents and reproducible pipelines.

### `workflow apply`

Create nodes and connections **atomically** (all-or-nothing) from a YAML spec.
Save this as `discovery.yaml` in your current directory. It adds one Python script
node; it does not execute the script:

```yaml
nodes:
  - name: example-script
    script: python
    code: |
      print("Example output")
```

Select the destination with `workflow use <workflow-id>`, then preview before applying:

```bash
trickest workflow apply -f discovery.yaml --dry-run   # preview without saving
trickest workflow apply -f discovery.yaml             # save the change
```

| Flag | Description |
|---|---|
| `-f, --file <path>` | YAML spec file (reads stdin if omitted) |
| `--force` | Skip conflicting nodes instead of erroring |
| `--dry-run` | Preview changes without saving |

### `workflow patch`

Apply targeted updates to **existing** nodes from YAML. Save this as
`changes.yaml` after adding `example-script` above. Patch keys are existing node
names, not a `nodes` array:

```yaml
example-script:
  label: Example script
  code: |
    print("Updated output")
```

Preview the patch before saving it:

```bash
trickest workflow patch -f changes.yaml --dry-run
trickest workflow patch -f changes.yaml
```

| Flag | Description |
|---|---|
| `-f, --file <path>` | YAML patch file (reads stdin if omitted) |
| `--dry-run` | Preview changes without saving |

<Tip>
`apply` is for adding structure (nodes + edges) transactionally; `patch` is for
tweaking nodes that already exist. Pair either with
[`graph validate`](/docs/developer-tools/cli/graph) to catch cycles and broken
connections before you run.
</Tip>

## Import a public snapshot

```bash
trickest workflow import --url <snapshot-json-url> --name "Imported workflow" --use
```

The URL must return a Trickest workflow snapshot. `--use` selects the imported
workflow as active context; without it, the command leaves your active context alone.
Importing a snapshot creates a workflow; it does not execute it.

## Recipe: build loop

```bash
trickest workflow create "Discovery" 
trickest workflow use "Discovery"
trickest node add subfinder --tool subfinder
trickest node add httpx --tool httpx --from subfinder
trickest graph validate            # catch issues

# Inspect and configure the tool inputs before execution:
trickest node info subfinder
trickest node info httpx
# After providing your authorized target and required inputs:
trickest run execute --dry          # preview the execution plan
```

## Related

<CardGroup cols={2}>
  <Card title="Nodes & Connections" icon="circle-nodes" href="/docs/developer-tools/cli/nodes">
    Add, configure, connect, and distribute nodes in the active workflow.
  </Card>
  <Card title="Graph Analysis" icon="sitemap" href="/docs/developer-tools/cli/graph">
    Validate, analyze, and explore the workflow DAG.
  </Card>
</CardGroup>

---
_Markdown source of https://trickest.com/docs/developer-tools/cli/workflows._