Workflows are folders

A workflow is a folder

A Cori workflow is a directory you can point cori run at. It contains a manifest, shared types, numbered step files, and optional tests:

translate_product_sheets_fr/
  manifest.md          # title, description, version, parameters, tools required
  types.ts             # shared Zod input/output types
  steps/
    01_read_source_rows.ts
    02_translate_rows.ts
    03_check_gpsr.ts
    04_ensure_fr_tab.ts
    05_write_results.ts
  tests/
    03_check_gpsr.test.ts

That's it. No configuration file outside the folder, no separate project setup, no compile step you run manually.

Run by path or git ref

You run a workflow by pointing at its folder:

# Local path
cori run ./translate_product_sheets_fr input_file=products.csv

# Git ref (go-module style)
cori run github.com/org/workflows/translate_product_sheets_fr@v1.1.12

Cori resolves the folder, compiles the steps, and executes. See Remote refs for the full ref syntax.

No registry, no IDs

There is no central registry, no cori init command to register a workflow, and no IDs to look up. Discovery is: "do you have the folder path, or a git ref?"

Workflows live in user-owned repositories. Cori never writes into a workflow folder after it's authored — it reads from it each run.

Where Cori's own state lives

Cori stores its own state in ~/.cori/:

• ~/.cori/runs/ — JSON run traces
• ~/.cori/cache/ — compiled workflow artifacts and remote ref fetches
• ~/.cori/config.toml — your configuration

See On-disk layout for the full tree.