dag-library

Use this skill when the user wants to KEEP a dag definition and run it again later, the graph is an asset, not a one-off. For authoring a brand-new graph, read mass-ulw first; this skill covers the storage-and-rerun half.

The shape

A stored definition is a plain dag definition JSON file named <name>.json in one of the library dirs. First hit wins:

1. $OMO_DAG_LIBRARY (multiple dirs, separated by :, or by ; on Windows, so drive-letter paths survive)
2. $PWD/.omo/dags
3. $HOME/.omo/dags

{
  "key": "nightly-audit",
  "name": "Nightly audit",
  "nodes": [
    { "id": "audit", "category": "unspecified-low", "prompt": "Audit docs/ for stale claims; write findings to /tmp/audit-{{key}}.md." },
    { "id": "verify", "category": "quick", "prompt": "Verify each finding in /tmp/audit-{{key}}.md against src/.", "dependsOn": ["audit"] }
  ]
}

String values may carry placeholders, filled at load time: {{key}} (the final rotated key, use it in file paths so reruns never clobber each other), {{date}} (UTC YYYYMMDD), {{datetime}} (UTC YYYYMMDD-HHmmss). Node prompts must still stand alone: dependsOn is ordering only, so pass data between nodes through files, exactly as in mass-ulw.

Running it, JS eval cell, two lines

The extension publishes library.js next to sdk.js at OMO_DAG_SDK_ROOT:

const lib = await import(`${env("OMO_DAG_SDK_ROOT")}/library.js`)
const run = await lib.start("nightly-audit")
const result = await run.done()

await lib.load(name) returns the filled definition without starting it; await lib.start(name) loads and starts in one call and returns the same handle shape as sdk.start (run_id, done(), cancel(reason)). Both are async, the kernel's read global is async, so never call them un-awaited.

Key rotation, the one rule that matters