Why Loom
Loom lets you keep local build and test commands in a versioned workflow and inspect their execution results through linked files. It may be useful when you want a CLI workflow runner whose output you can also read from scripts or an AI agent.
What you can use it for
Run local workflows
- Define build and test jobs in YAML
- Validate the workflow before execution
- Run commands on the host or in Docker
- Declare cache paths and secret references
Inspect execution results
- Read pipeline and job status from JSON
- Follow manifests to a failed script entry
- Inspect system sections for provider failures
- Share the files needed to investigate a run
Finding the relevant output
A run receipt's logs_dir locates the runtime directory. Its pipeline/manifest.json identifies the failing job and the job manifest, which links to step and system-section event streams. An agent can use those links to select the output to read.
The selected stream contains evidence to investigate, not a guaranteed diagnosis. A test runner can report many failures in one script entry, and setup errors can happen before a receipt exists. The diagnostics ladder explains where to start in each case.
To hand off a run, share its receipt and relevant runtime files, along with the path context needed to resolve their links. File sizes depend on the workflow and its output. See what to share.
Limits to consider
Loom is a CLI-first, evaluation-stage release. Alpha 1 runs locally with host and Docker-backed jobs on Linux; remote execution and shared runners are planned. Its contracts may change between releases.
Read the support boundary and check the relevant provider and workflow references before adopting a capability.
See it for yourself
Run the Hello Loom example.
Run a small workflow, introduce a failure, and inspect the files Loom writes.