orcr scaffold
the one purely-local command: it generates a ready-to-run TypeScript workflow project and runs npm install, without touching the server.
orcr scaffold sets up a minimal, ready-to-run TypeScript workflow project, the recommended way to write anything with real control flow (fan-out with retries, classify-and-act, a loop's script) instead of chaining --json and jq in bash.
orcr scaffold [<dir>] [--json]it creates exactly three files in <dir> (default: the current directory; created if missing) and runs npm install:
| file | contents |
|---|---|
package.json | @orchestratr/sdk (pinned to this CLI's version), plus tsx and typescript |
tsconfig.json | a minimal TypeScript config |
workflow.ts | a runnable ~15-line example: scope → run --name → wait → last-response, with one comment pointing at the skill reference |
run it with npx tsx workflow.ts; add more .ts files freely. it is a plain npm project, so any extra dependency the workflow needs (a GitHub client, a CSV parser) is one npm install away, and a human can review the code like any other code.
rules
- requires Node ≥ 20 and npm on the machine. missing →
environment_errorwith an install pointer, and nothing is created. this is the only orcr feature that needs Node; the CLI itself does not. - never overwrites. if any of the three files already exists in
<dir>, the command fails withstate_conflictand touches nothing. - purely local. this is the one command that does not talk to the server: no store row, no auto-start. the project it generates talks to the server like any SDK client, and the socket version check catches CLI/SDK drift loudly.
ORCR_SDK_SPECoverrides the dependency spec: set it to a local tarball or path for offline/local installs; otherwise the pinned CLI version is used.
TypeScript only in the first release; a language argument (orcr scaffold py) is future work.
where to put projects
this is convention, not CLI behavior: the CLI never enforces where a project lives, and the skill teaches it:
- a one-time dynamic workflow goes to
$ORCR_AGENT_DATA_DIR/workflows/: it dies with the agent's other artifacts, but stays auditable. - anything reusable, including every loop's script, goes to
~/.orcr/workflows/<name>/. a loop is by definition reusable, so its command points at this project whiledata/<loop>/keeps only runtime state.
see data and file conventions and the SDK workflows guide.