Skip to main content

​
crewship automation

Manage automations — the workspace rules that turn a journal event into a deferred routine run. See the Automations guide for the concepts, the burst controls and the {{ event.* }} template namespace.

​
Subcommands

Every subcommand honours the global --format flag (json/yaml/ndjson) — see Output Formats.

​
crewship automation preview

Replay recent history against a rule and see what it would have caught — without saving anything and without starting a run.
A matcher is otherwise written blind: you save it, wait, and notice nothing happened. When a preview finds nothing, it names the clause that excluded the most entries and what was actually there:
The fix is in the last line: the event spells the new status to, not status. Re-run with --payload-equals to=DONE and the preview fires.
“no entries in the window” is not a verdict on the rule. A quiet workspace has nothing to judge a matcher against; the output says so rather than reporting zero matches, which would send you to edit a predicate that may be perfectly correct.

​
crewship automation list

Sample output:

​
crewship automation create

--name, --event and --routine are required. The routine must already exist in this workspace; a slug that does not resolve is refused rather than saved as a rule that never fires. A predicate flag you omit is “don’t care”; omit all of them and every entry of the event type matches.
Check the payload before you match on it. A --payload-equals key that no emitter writes is accepted, saved, listed — and matches nothing, forever, with no error anywhere:
mission.status_change carries exactly two keys: action (a closed set — status_changed, review_approved, task_failed, …) and details (prose, e.g. "BACKLOG → TODO"). Match on action; read details inside the routine via {{ event.payload.details }}. “Moved to DONE” is not expressible as a predicate — the target status lives only in that prose. See Automations → what mission.status_change actually carries.

​
crewship automation update <id>

Sparse: only the flags you pass are sent, so changing the cap cannot clobber a matcher somebody edited a moment ago. Accepts the same flags as create.
The action is written as a whole, so --input requires --routine. Sending inputs alone would blank the rule’s target.
The write is sparse — except for the matcher, which the API stores as one object. Passing any predicate flag replaces every predicate, so a rule scoped to a crew and updated with --payload-equals alone would silently stop being crew-scoped and start firing workspace-wide.The CLI refuses that and names what would be lost. Re-supply the predicates you want to keep, or pass --replace-matcher if dropping them is what you meant.

​
crewship automation enable <id> / disable <id>

A disabled automation never matches. Both are the same sparse write as update --enabled, exposed as verbs because that is how they are used.

​
crewship automation delete <id>

Soft-delete: the rule stops matching immediately, and the row is retained rather than dropped, so the runs it caused are never orphaned. The rule is filtered out of every read once deleted, including crewship chain. Its runs keep triggered_via='automation', so the record that a rule started them survives, but the rule itself no longer appears as a node. Use crewship automation disable <id> instead when you want to stop a rule and keep the origin of its past runs visible in the topology.

​
Trace what a rule has done

Shows the routine the rule is wired to and every run it has caused. See crewship chain.

​
Exit codes

Standard CLI exit codes. A routine slug that does not exist in the workspace, a malformed --event, or a key=value flag without an = are all client errors, reported before anything is written.