/Catalogue/Prompt/code-yeongyu/code-yeongyu-oh-my-openagent-dag-library

Origin: github

dag-library

Stores a DAG definition once and re-runs it by name, instead of pasting the definition into every run. Use when the user wants to save a DAG, run a saved one, or schedule the same multi-agent graph repeatedly.

by code-yeongyu · updated 15h ago · imported from GitHub

Installs0+0/7d
Security score73/100
Retention 14d0%
GitHub stars69.4K

Skill logic

Execution graph
User message
Prompt rewrites behaviour
Response

SKILL.md

View on GitHub ↗

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

The dag engine keys idempotency on key + graph fingerprint: re-starting the same key with the same graph REUSES the old run instead of running again. So the library treats the stored key as a BASE key and rotates it on every load:

  • lib.start("nightly-audit") → key becomes nightly-audit-<UTC YYYYMMDD-HHmmss>: every call is a fresh run. This is the default because wanting a fresh run is the common case.
  • lib.start("nightly-audit", { suffix: "20260818" }) → key becomes nightly-audit-20260818: explicit suffix, so re-running the same logical run reuses it (idempotent recovery), while a new day gets a new run. Recovering a FAILED node inside such a run is retry/amend on that run id, not a new suffix.
  • lib.start("nightly-audit", { suffix: "" }) → key stays nightly-audit: full idempotency; only reach for this when reusing the previous result is exactly what you want.

Python cells

Python cannot import the ESM library. Reproduce the same semantics with plain dicts — read the file, rotate the key, fill placeholders, call tool.workflow:

import json
from datetime import datetime, timezone
defn = json.loads(read(f"{env('HOME')}/.omo/dags/nightly-audit.json"))
stamp = datetime.now(timezone.utc).strftime("%Y%m%d-%H%M%S")
defn["key"] = f"{defn['key']}-{stamp}"
text = json.dumps(defn).replace("{{key}}", defn["key"]).replace("{{date}}", stamp[:8]).replace("{{datetime}}", stamp)
run = tool.workflow({"action": "start", "definition": json.loads(text)})
result = tool.workflow({"action": "wait", "run_id": run["run_id"], "detach": False})  # detach=False keeps the cell-blocking wait; the bare tool action detaches against a live run

Saving a new definition

When the user asks to save the current graph: write it as <name>.json into $HOME/.omo/dags (user-level, survives cwd changes) or <repo>/.omo/dags (project-level, shareable through git if the team commits it), then confirm by running it once via lib.start. Names are letters, digits, dot, dash, underscore — the library rejects path-shaped names.

Discussion

No comments yet — start the thread.

Sign in to join the discussion.

/More from code-yeongyu/oh-my-openagent

code-yeongyu· 15h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
pre-publish-review

Prompts · TypeScript · v0.1.0

Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
codex-qa

Prompts · TypeScript · v0.1.0

QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.

#ai#ai-agents#anthropic

0 69.4K