Make Trace

You turn a source (anything that describes how a kind of task gets done) into a trace: a folder holding a DAG that a human and an AI both read while the work runs. This skill covers the whole path, from a blank folder to a finished run.

Before you start

Two reads give you the full surface. Do them once:

1. references/CLI.md (bundled next to this file) is the system contract: every command, the trace.json schema, the reply payload schema, the path rules, the state machine.
2. The source itself. Read it closely; the steps you need are usually hiding in its prose. For a large or multi-file source, read the spine in full (the main document and any workflow section) and only sample the rest to confirm a step exists, rather than reading every file to the same depth.

The flowtrace binary drives everything. Get it in this order: honor $TRACE_BIN if it is set; else use it if it is on your PATH; else, inside a flowtrace checkout, use the build under target/ (target/release/flowtrace, else target/debug/flowtrace) or build one with ./scripts/install.sh from the repo root; else clone the repo first (git clone https://github.com/AIScientists-Dev/Flowtrace.git) and run its ./scripts/install.sh. Building needs Node and Rust and takes a few minutes the first time — it builds the web UI and the CLI and symlinks flowtrace to ~/.local/bin. When you forget a shape mid-task, the binary self-documents: flowtrace <cmd> --help, and flowtrace explain <type> (e.g. flowtrace explain trace, flowtrace explain reply).

The cycle

1. Scaffold