skills/dag-pattern-learner/SKILL.md
Learns from DAG execution history to improve future performance. Identifies successful patterns, detects anti-patterns, and provides recommendations. Activate on 'learn patterns', 'execution patterns', 'what worked', 'optimize based on history', 'pattern analysis'. NOT for failure analysis (use dag-failure-analyzer) or performance profiling (use dag-performance-profiler).
npx skillsauth add curiositech/windags-skills dag-pattern-learnerInstall 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 Pattern Learner that extracts actionable insights from execution history to improve future DAG performance.
Sample Size >= 10?
├─ Yes: Weight by recency (40%) + frequency (35%) + outcome quality (25%)
├─ No: Sample Size >= 5?
├─ Yes: Weight by outcome quality (50%) + frequency (30%) + recency (20%)
└─ No: Flag as "Insufficient Data" (confidence < 0.6)
Outcome Quality Score:
├─ Success Rate >= 90%: Quality = 1.0
├─ Success Rate >= 75%: Quality = 0.8
├─ Success Rate >= 60%: Quality = 0.6
└─ Success Rate < 60%: Quality = 0.3
Recency Decay:
├─ Last 7 days: Multiplier = 1.0
├─ Last 30 days: Multiplier = 0.8
├─ Last 90 days: Multiplier = 0.6
└─ Older: Multiplier = 0.3
Execution Count >= 3?
├─ No: Skip (insufficient data)
└─ Yes: Pattern Type?
├─ Same skill sequence: Extract skill combination pattern
├─ Same graph structure: Extract topology pattern
├─ Similar parallel groups: Extract parallelization pattern
└─ Similar retry behavior: Extract retry strategy pattern
Confidence Threshold:
├─ High-stakes recommendation (affects cost/security): Require 0.8+
├─ Performance optimization: Require 0.7+
├─ Structural suggestion: Require 0.6+
└─ Experimental hint: Accept 0.5+
High Variance Detected (CV > 0.5)?
├─ Yes: Check execution success rate
│ ├─ Success < 70%: Flag as "Unstable Pattern"
│ └─ Success >= 70%: Flag as "Performance Inconsistency"
└─ No: Check resource efficiency
├─ Token waste > 30%: Flag as "Resource Waste"
├─ Avg retries > 2.0: Flag as "Retry Storm"
└─ Bottleneck node > 40% total time: Flag as "Sequential Bottleneck"
Severity Classification:
├─ Critical: Success rate < 50% OR Cost increase > 100%
├─ High: Success rate < 70% OR Cost increase > 50%
├─ Medium: Success rate < 85% OR Cost increase > 25%
└─ Low: Minor efficiency issues
Symptoms: All patterns have suspiciously high confidence scores (>0.9), minimal variance in outcomes Detection Rule: If 80%+ of patterns have confidence >0.85 AND outcome variance <0.1, flag this anti-pattern Fix: Increase minimum sample size requirements, add variance penalty to confidence calculation, implement skeptical scoring for edge cases
Symptoms: Highly specific patterns with narrow applicability conditions, low reuse across different contexts Detection Rule: If pattern has >5 applicability conditions OR only matches <3% of new executions, flag as overfitted Fix: Generalize conditions by removing context-specific constraints, merge similar patterns, focus on structural rather than content-based patterns
Symptoms: Pattern confidence doesn't decrease despite recent failures, outdated patterns maintain high scores Detection Rule: If pattern confidence >0.7 but recent 10 executions show <60% success rate, flag as inflated Fix: Implement exponential decay for confidence based on recency, weight recent failures more heavily, add "drift detection" to flag changing behavior
Symptoms: Making strong recommendations from tiny samples, treating n=3 same as n=100 Detection Rule: If recommendation confidence >0.7 with sample size <10, or >0.8 with sample size <20, flag this issue Fix: Apply confidence penalties for small samples, require minimum thresholds for different recommendation types, show sample size prominently in outputs
Symptoms: Patterns extracted without considering execution context, applying database patterns to API tasks Detection Rule: If pattern shows success in one domain but <40% success when applied cross-domain, flag context collapse Fix: Include execution context in pattern matching, create domain-specific pattern libraries, add context similarity scoring before pattern application
Input: 15 executions of "data-validator + api-client + result-formatter" sequence
- Success rates: 90%, 85%, 95%, 40%, 92%, 38%, 88%, 45%, 91%
- CV = 0.31 (high variance, but not >0.5 threshold)
- Average success: 73%
Decision Process:
1. Check variance: CV=0.31 < 0.5, proceed to resource check
2. Calculate token waste: Failed executions wasted 920 tokens avg
3. Waste ratio: 920/(920+1240) = 42% > 30% threshold
4. Flag as "Resource Waste" anti-pattern
Pattern Creation Decision:
- Success rate 73% >= 70%, so not "Unstable Pattern"
- High token waste suggests late-stage failures
- Extract pattern BUT flag remediation: "Add early validation step"
Output Pattern:
- Name: "API Validation Chain"
- Confidence: 0.65 (penalized for waste)
- Recommendation: "Insert input validator before expensive API calls"
Input: Execution showing 3 analysis skills running sequentially (45s total)
- code-complexity-analyzer: 15s
- code-security-scanner: 18s
- code-performance-analyzer: 12s
- No dependencies between them found in execution trace
Decision Process:
1. Identify parallel candidate group: all 3 skills
2. Check historical data for similar skill combinations
3. Find 8 previous executions with these skills:
- 5 sequential (avg 44s), 3 parallel (avg 19s)
- Parallel success rate: 100%, Sequential: 87%
4. Calculate benefit: 44s → 19s = 57% improvement
Pattern Weight Calculation:
- Recency: Last parallel execution 5 days ago = 0.8 multiplier
- Frequency: 3/8 = 37.5% of executions used parallel
- Outcome quality: 100% success = 1.0 score
- Final weight: (0.8×0.4) + (0.375×0.35) + (1.0×0.25) = 0.71
Output: High-confidence parallelization recommendation
Input: Pattern library with 23 skill combination patterns
Analysis Process:
1. Extract skill co-occurrence matrix:
- "file-reader" + "json-parser": appears in 12 patterns
- "json-parser" + "data-validator": appears in 15 patterns
- "file-reader" + "data-validator": appears in 8 patterns
- All three together: appears in 6 patterns
2. Calculate synergy scores:
- Expected co-occurrence (random): 12×15×8/(23³) = 0.99
- Actual co-occurrence: 6
- Synergy ratio: 6/0.99 = 6.06 (strong positive synergy)
3. Cross-reference outcomes:
- Patterns with all three: 94% avg success rate
- Patterns missing one: 78% avg success rate
- Improvement delta: 16 percentage points
Decision: Create synergy recommendation
- Title: "File Processing Trinity"
- Confidence: 0.82 (strong statistical evidence)
- Applicability: "When processing structured file data"
Do NOT use dag-pattern-learner for:
dag-failure-analyzer insteaddag-performance-profiler insteaddag-task-scheduler insteaddag-graph-builder insteadDelegate when:
dag-failure-analyzerdag-performance-profilerdag-graph-builderdata-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.