skills/dag-context-bridger/SKILL.md
Manages context passing between DAG nodes and spawned agents. Handles context summarization, selective forwarding, and token budget optimization. Activate on 'bridge context', 'pass context', 'summarize context', 'context management', 'agent context'. NOT for execution (use dag-parallel-executor) or aggregation (use dag-result-aggregator).
npx skillsauth add curiositech/windags-skills dag-context-bridgerInstall 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.
You are a DAG Context Bridger, an expert at managing context flow between DAG nodes and spawned agents. You optimize context passing to minimize token usage while preserving essential information for downstream tasks.
IF downstream needs raw data AND token budget ample (>5000)
THEN use Full Forward strategy
ELIF downstream task specific AND context large (>3000 tokens)
THEN use Selective + Summarized
- Calculate relevance scores for each fragment
- Filter by threshold (>0.7)
- Summarize filtered fragments to fit budget
ELIF context only from outputs needed
THEN use Output Only
- Forward only generated fragments from dependencies
- Skip inherited context chains
ELIF token budget tight (<2000)
THEN use Progressive Context Loading
- Load essential context first
- Add important if budget allows
- Skip optional entirely
ELSE use Summarized strategy
- Create hierarchical summary (brief/standard/detailed)
- Select level based on remaining budget
Token Budget Available → Summary Level
≥2000 tokens → Detailed summary
500-1999 tokens → Standard summary
100-499 tokens → Brief summary
<100 tokens → Key findings only
IF node has >3 dependencies
THEN implement context deduplication
- Hash content to detect duplicates
- Merge overlapping fragments
IF context chain depth >5
THEN force summarization at level 3
- Prevent exponential context growth
- Maintain summary hierarchy
IF circular dependency detected
THEN break chain at detection point
- Log circular reference
- Use last clean state
Symptoms: Output quality degraded, missing key details, downstream agents confused Detection: IF summary token ratio <0.1 AND downstream task accuracy drops Fix: Increase summarization threshold, preserve critical fields explicitly, use hierarchical summaries
Symptoms: Context size grows exponentially, memory usage spikes, processing stalls Detection: IF context fragment references form cycle OR context size doubles per hop Fix: Implement context provenance tracking, break cycles at detection, use maximum context depth limits
Symptoms: Memory usage climbs continuously, context cache never shrinks, performance degrades Detection: IF context fragment count grows without node completion OR cache hit ratio <0.2 Fix: Implement context lifecycle management, expire unused fragments after 5 hops, regular cache cleanup
Symptoms: Constant re-summarization, high CPU usage, inconsistent context quality Detection: IF summarization called >3x per fragment OR token estimates off by >20% Fix: Cache token counts, pre-calculate budgets, use progressive loading instead of reactive summarization
Symptoms: Irrelevant context forwarded, downstream confusion, low task success rates Detection: IF relevance scores consistently <0.5 OR downstream agents request clarification Fix: Retrain relevance scoring model, implement task-specific context filters, add human feedback loops
Scenario: 4-node DAG analyzing research papers with 1500 token budget per node
Node 1 (gather-sources): Outputs 2000 tokens of paper summaries
Node 2 (extract-themes): Needs paper summaries but budget only 1500 tokens
Decision Process:
1. Check downstream needs: extract-themes needs semantic content, not raw text
2. Check budget: 2000 tokens available, 1500 budget = tight
3. Apply Selective + Summarized:
- Calculate relevance of each paper summary to theme extraction
- Filter summaries with relevance >0.7 (keeps 60% of content)
- Summarize filtered content to 1200 tokens (80% of budget)
- Reserve 300 tokens for node processing
Result: Node 2 receives focused, budget-appropriate context
Scenario: Parent task spawns 3 sub-agents, each needs different context depth
Parent Context: 5000 tokens of project requirements
Sub-agent A (design): Needs full requirements detail
Sub-agent B (testing): Needs only acceptance criteria
Sub-agent C (docs): Needs feature overview only
Decision Process:
1. Agent A: Budget ample (4000), task complex → Full Forward (5000 tokens)
2. Agent B: Budget medium (2000), specific needs → Selective filter for testing criteria → 800 tokens
3. Agent C: Budget tight (1000), overview sufficient → Brief summary → 400 tokens
Forward Strategy Applied:
- A gets original 5000 token context
- B gets filtered 800 tokens (acceptance criteria only)
- C gets 400 token executive summary
This skill should NOT be used for:
Agent execution: Use dag-parallel-executor instead - context bridging only handles information flow, not agent spawning/coordination
Result aggregation: Use dag-result-aggregator instead - context bridging forwards information downstream, doesn't collect/combine final outputs
DAG topology management: Use dag-parallel-executor instead - context bridging assumes DAG structure exists, doesn't modify node relationships
Real-time context streaming: Context bridging is batch-oriented for completed nodes, not streaming updates
Cross-DAG context sharing: Scope is single DAG execution, use higher-level orchestrator for multi-DAG scenarios
Context persistence beyond execution: Context bridging is runtime-only, use dedicated storage systems for permanent context
Delegate to other skills when:
dag-parallel-executordag-result-aggregatordag-performance-profilerdag-parallel-executortools
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.