skills/dag-runtime/SKILL.md
Executes DAG workflows with parallel wave processing, agent spawning, context isolation, permission enforcement, and full execution tracing. Use when running a planned DAG, managing concurrent agent execution, enforcing isolation boundaries, or tracing execution for debugging. Activate on "execute DAG", "run workflow", "spawn agents", "parallel execution", "execution trace", "agent isolation". NOT for planning DAGs (use dag-planner), validating outputs (use dag-quality), or matching skills (use dag-skills-matcher).
npx skillsauth add curiositech/windags-skills dag-runtimeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Executes DAG workflows with parallel wave processing, agent spawning, context isolation, permission enforcement, and full execution tracing.
Input: threat model + node characteristics
├── Untrusted code execution?
│ └── YES → Container isolation
├── Resource limits needed?
│ └── YES → Process isolation
├── Context contamination risk?
│ └── YES → Context isolation
└── Cooperative nodes on same task?
└── YES → None isolation
Node fails → Check failure type:
├── Timeout/Rate limit?
│ └── Retry with exponential backoff (max 3x expensive models, 10x cheap)
├── Invalid output schema?
│ └── Retry with schema reminder + example (max 2x)
├── Permission denied?
│ └── Check parent permissions → escalate to human if mismatch
├── Skill not found?
│ └── Mutate DAG: remove node or find alternative skill
└── Persistent failure after max retries?
└── Human review required
All nodes in wave complete → Check status:
├── All succeeded?
│ └── Advance to next wave
├── Some failed but non-blocking?
│ └── Mark outputs as null, advance with warning
├── Critical node failed?
│ └── Halt execution, trigger failure handling
└── Mixed success/retry?
└── Wait for retries to complete
if child.permissions.tools ⊃ parent.permissions.toolsScenario: 3-wave codebase analysis DAG where Wave 2 node fails
# Initial DAG state
Wave 1: [scan-files] → completed
Wave 2: [analyze-architecture, check-security] → analyze-architecture fails
Wave 3: [generate-report] → blocked
Decision Navigation:
analyze-architecture returns malformed JSONcheck-security succeeded, output availableanalyze-architecture failed, mark output as nullgenerate-report requires both outputs
required: false → advance with warningrequired: true → halt executionExpert catches: Checking dependency requirements before advancing wave Novice misses: Would either block forever or advance with missing critical data
Scenario: Code execution node needs filesystem access but has security concerns
node: code-formatter
skills: [python-formatter]
inputs: {source_files: [...]}
permissions: {tools: [Read, Write, Bash], paths: ["/workspace/src"]}
Decision Navigation:
/workspace/src → /container/workspaceExpert catches: Need to balance security with functionality Novice misses: Would either over-isolate (breaking functionality) or under-isolate (security risk)
Don't use dag-runtime for:
dag-planner insteaddag-quality insteaddag-skills-matcher insteadDelegate to other skills when:
dag-qualitydag-plannerdag-skills-matchertools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.